2.1.2.1 Abstract Components
The following block diagram illustrates abstract components that are involved in the network logon process. Network logon authentication is performed when an application uses underlying authentication protocol packages through the GSS-API layer to establish a secure network connection. Network logon authentication is the mechanism at work when a user connects to multiple machines on a network. For example, if an application needs to open a secure folder on a remote machine and the application user is already logged on to a domain user account, the application does not require the user to supply logon data again. Instead, the application requests network logon authentication by using the GSS-API layer to pass the previously established security information to underlying security support providers (SSPs).
Figure 5: Network logon authentication architecture
The preceding diagram shows the network logon authentication architecture that distributed client and server applications in a domain environment use. The communication between the client and server applications can occur over application communication protocols that are LAN-oriented ([MS-SMB], [MS-SMB2], [MS-CIFS], and [MS-RPCE]) or Internet-oriented (HTTP, [MS-POP3], [MS-NNTP], and Lightweight Directory Access Protocol (LDAP)).
The GSS-API is an application programming interface standard [RFC2743] that insulates application communication protocols and authentication protocols.
GSS-API main functionality
The primary purpose of GSS-API is to abstract the commonalities of different authentication protocols and to hide their implementation details.
A related purpose is to disentangle application communication protocols from authentication protocols. An authentication protocol should be available to any application communication protocol. Its implementation should not contain any application protocol-specific information.
To facilitate application protocol interactions with authentication protocols, GSS-API uses the abstractions of credentials and security contexts. Credentials authenticate a security principal, such as a user name, password, or certificate. In a GSS-API client and server scenario, each party provides some type of credential. GSS-API uses these credentials to perform the authentication. A security context is a collection of authenticated information about a security principal for an instance of a session.
Throughout the GSS-API authentication process, the client and server exchange partial context information in the form of security tokens. In this process, the GSS-API client and server each initially obtains credentials and then calls the GSS-API to create security tokens to send to its counterpart. Likewise, when a GSS-API client or server receives a security token from the other, it uses the GSS-API to process and incorporate the security token, which contains authentication protocol-specific data, into the security context for the authenticated relationship.
In GSS-API authentication, the client and server send and receive security tokens until authentication succeeds or fails. After successful GSS-API authentication, the client and server each has a security context that establishes an authenticated relationship with the other. These security contexts do not contain the credentials that are used to create them, however, they can contain information from the authentication process that is useful to the application for securing communications, such as an encryption key. They can also contain information for maintaining the authenticated connection, such as a Kerberos ticket or certificate or other information that is useful in authorizing the client's request, such as security claims about the client. The security support provider (SSP) that performs the authentication determines the contents of the context.
The following diagram illustrates GSS-API authentication between client and server application protocols.
Figure 6: GSS-API authentication process