1.1.3 GSS-Style Authentication
In the 1990s, a new paradigm decoupled application protocols from authentication protocols. This approach, which became the Generic Security Service Application Programming Interface (GSS-API), simplified the interactions between the application protocols and authentication protocols. The Generic Security Services (GSS) style or GSS model underlies most currently implemented authentication protocols that interact directly with application protocols. In the GSS style or model, the authentication protocol produces opaque messages that are known as security tokens. The application protocol is responsible for security token exchange between sender and receiver but does not parse or interpret the security tokens.
Client-side requests and server responses usually drive GSS authentication.
The Authentication Services protocols provide authentication services to client and server applications. As illustrated in the following diagram, client and server applications interact with the Authentication Client and Authentication Server components of Authentication Services. Additionally, the client and server applications communicate directly with their counterparts.
Figure 1: GSS-style authentication model
As shown in the preceding diagram, the client application contacts the local Authentication Client through a generic interface that abstracts the underlying authentication protocols for creating a security token. The Authentication Client creates a security token with the help of the underlying authentication protocols and returns it to the calling application. Next, the client application embeds the security token within application messages of the application protocol and transmits them as an authentication request to the server side of the application. On receipt of the authentication messages, the server application extracts the security token and supplies it to the Authentication Server. The Authentication Server processes the security token with the help of the underlying authentication protocols and generates a response or determines that authentication is complete. If another security token is generated, the server-side application sends it back to the client, where the process continues.
This exchange of security tokens continues until one or both sides determine that authentication is complete. If authentication fails, the application should drop the connection and indicate the error. If it succeeds, the application can then be assured of the identity of the participants, as far as the underlying authentication protocol can accomplish.
When authentication is complete, session-specific security services are available. The application can then invoke the authentication protocol to sign or encrypt the messages that are sent as part of the application protocol. These operations are performed in much the same way, where the application can indicate which portion of the message is to be encrypted, and then include a per-message security token. By signing and/or encrypting the messages, the application obtains privacy, resists message tampering, and detects dropped, suppressed, or replayed messages.
In Windows, the Security Support Provider Interface (SSPI) is the implementation of the GSS-style authentication model. SSPI is a Windows-specific API implementation that provides the means for connected network applications to call one of several security support providers (SSPs) to establish authenticated connections and to exchange data securely over those connections. SSP is the implementation of an authentication protocol as a dynamic link library (DLL). SSPI is the Windows equivalent of GSS-API, and the two sets of APIs are on-the-wire compatible; hence, in this document, the terms GSS-API and SSPI are used interchangeably.
For more information about the SSPI, see [SSPI].