Secure Sessions

A secure session is one that can be joined only by authenticated users. This is not the same as password protection. Authentication verifies that the user is allowed access to the server by virtue of having been added to the membership database by the administrator of the server. Only users that are part of the membership database are permitted to join the session. A password can be added to any session, regardless of whether it is a secure session. Secure sessions can be hosted only on computers that support authentication, but any computer can put a password on a session.

[C++]

Creating a secure DirectPlay session simply requires the server application to set the DPSESSION_SECURESERVER flag in the DPSESSIONDESC2 structure passed to IDirectPlay4::Open or IDirectPlay4::SecureOpen. Open can be used to create a session that uses the default security package and does not require authentication at the time when clients join the session.

A DirectPlay application can choose to use alternate providers when it creates a session by calling the SecureOpen method and specifying the providers to use in the DPSECURITYDESC structure. For a different SSPI provider (for user and message authentication), an application needs to specify the provider name in the lpszSSPIProvider member of the DPSECURITYDESC structure. For a different CryptoAPI provider (for message privacy), an application needs to specify the provider name, provider type, and encryption algorithm in the lpszCAPIProvider, dwCAPIProviderType, and dwEncryptionAlgorithm members respectively.

When a client enumerates this session, the DPSESSIONDESC2 structure returned by IDirectPlay4::EnumSessions will have the DPSESSION_SECURESERVER flag set. This tells the client that authentication credentials will be required to join the session. If the client attempts to join the session using IDirectPlay4::Open, the security package may allow the user in if the user's credentials were already established through a system log on. Otherwise, a DPERR_LOGONDENIED error is returned. The application must then collect credentials from the user, put them in a DPCREDENTIALS structure, and try to join the session again by calling IDirectPlay4::SecureOpen, passing in the DPCREDENTIALS structure. SecureOpen is recommended for security.

[Visual Basic]

Creating a secure DirectPlay session simply requires the server application to set the DPSESSION_SECURESERVER flag in the DirectPlaySessionData object passed to DirectPlay4.Open or DirectPlay4.SecureOpen. Open can be used to create a session that uses the default security package and does not require authentication at the time when clients join the session.

A DirectPlay application can choose to use alternate providers when it creates a session by calling the SecureOpen method and specifying the providers to use in the DPSECURITYDESC type. For a different SSPI provider (for user and message authentication), an application needs to specify the provider name in the strSSPIProvider member of the DPSECURITYDESC type. For a different CryptoAPI provider (for message privacy), an application needs to specify the provider name, provider type, and encryption algorithm in the strCAPIProvider, lCAPIProviderType, and lEncryptionAlgorithm members respectively.

When a client enumerates this session, the DirectPlaySessionData object returned by DirectPlayEnumSessions.GetItem will have the DPSESSION_SECURESERVER flag set. This tells the client that authentication credentials will be required to join the session. If the client attempts to join the session using DirectPlay4.Open, the security package may allow the user in if the user's credentials were already established through a system log on. Otherwise, a DPERR_LOGONDENIED error is returned. The application must then collect credentials from the user, put them in a DPCREDENTIALS type, and try to join the session again by calling DirectPlay4.SecureOpen, passing in the DPCREDENTIALS type.

Within a secure session, all DirectPlay system messages are digitally signed to verify the identity of the sender. Certain system messages that carry sensitive information are encrypted. System messages that originate from one player and need to be broadcast to all the other players in the session are first sent to the server. The server then puts its signature on the message and forwards the message to all the other computers in the session. By default, player-to-player messages are not signed and are not routed through the server.

An application can choose to sign or encrypt specific player-to-player messages by setting the DPSEND_SIGNED and DPSEND_ENCRYPTED flags when the message is sent. Signed and encrypted player messages are routed through the server and delivered as secure system messages. When a secure message is received by a player, the message will contain flags indicating whether the message came in signed or encrypted. Messages that do not pass the verification are dropped.