See Also
 Important: |
|---|
| This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
In a typical client/server application protocol, the server waits for the client to connect and request service. Upon connection, the server must be able to authenticate the client and the client must be able to authenticate the server. The protocol used to establish an authentic connection requires the exchange of one or more security tokens between the client and server SSP. The tokens, which include protocol-specific data, are sent as messages between the client and the server. The client and the server continue to exchange messages until either the authentication is successfully established or an error occurs.
Client Security Context
Initialization
To begin the authentication process, the client calls the AcquireCredentialsHandlefunction with the SECPKG_CRED_INBOUND flag to obtain an outbound credentials handle. Then, the client calls the InitializeSecurityContextfunction to obtain a security token to send a connection request message to the server.
The client uses the security token data received in the output buffer descriptor to generate a message to send to the server. The construction of the message, in terms of placement of various buffers, is decided by the application protocol and is adhered to by both client and server. For more information about buffers, see Memory Use and Buffers.
The client examines the return status of InitializeSecurityContextto determine if authentication is complete. The return status SEC_I_CONTINUE_NEEDED indicates that the security protocol requires additional authentication messages.
Server Security Context
Initialization
In a similar process, the server must also call the AcquireCredentialsHandlefunction with the SECPKG_CRED_OUTBOUND flag to obtain a handle to its credentials.
When the server receives a connection request from the client, it calls the AcceptSecurityContextfunction, passing the data that it received from the client as input. Rather than copying the data to an alternate buffer, the server initializes the security buffer descriptors to refer to specific sections of the data.
Next, the server checks the return status and output buffer descriptor to ensure that no errors exist. If errors do exist, the server rejects the connection request; if errors do not exist, the server checks the output buffer for data. If data is present in the buffer, the server bundles the data according to the application protocol, and then places the data into a response message to the client.
If the return status is SEC_I_CONTINUE_NEEDED or SEC_I_COMPLETE_AND_CONTINUE, another message exchange with the client is required. Otherwise, authentication is complete. If authentication must continue, the server waits for the client to respond with another message. Place a time-out on this waiting period in case the client does not respond with a message. A time-out will avoid the possibility of hanging this and, subsequently, all server threads.
For sample code example, see SSPI Sample Application.