Constrained delegation (S4U2Proxy)
In versions of Active Directory that support constrained delegation, delegation can be refined so that it works through the use of a series of “service tickets” instead of the transmission of the user's TGT. Using these tickets, it permits delegation of the client’s identity directed to one or more servers, but only to those specifically selected by configuration as being permitted to be authentication delegates.
In constrained delegation, the client does not send the TGT, it simply sends the service ticket. The server can then present this service ticket, along with the server's own TGT, to Active Directory in order to request a service ticket using constrained delegation to another service. Active Directory will only grant service tickets from the server to a specific list of services that have been previously configured.
Constrained delegation may be repeated through multiple tiers. For each tier, a domain controller is responsible for issuing a new service ticket and checking whether the authenticated server is permitted to perform constrained delegation to the next server.
The following graphic shows you a simplified summary of the sequence of events involved in the Constrained delegation (S4U2Proxy) processes.
Figure 2: Constrained Delegation with S4U2Proxy
Protocol transition (S4U2Self)
Clients that need access to Active Directory services can include external clients, which for a variety of reasons do not have immediate access to facilities for a full exchange of credentials under Kerberos.
Some clients may use alternative authentication methods such as SSL client certificates, HTTP digest authentication, or NTLM authentication.
Some external clients may operate through a firewall, where Kerberos operations are generally considered inappropriate, but where the client is still required to authenticate, and there is a need for Single Sign-on access to internal services.
Such external clients might be able to be granted access via Active Directory's Kerberos environment if the internal server were to be passed the client's full logon details or its TGT.
However, this is not a preferred approach, and on a strict application of security principles, might be seen as serious breach of the trust rules for a secure system.
For Windows Server 2003 and higher domain function levels, the solution for this is the “protocol transition” (S4U2Self) extension.
This allows the server itself to collect sufficient information about the client to establish a logon token which clears it for access without the need for a user password.
Under this arrangement, the server, rather than the client, requests a Kerberos ticket for itself, on behalf of the “otherwise-authenticated” client.
The following figure illustrates the event sequence involved (in simplified terms).
Figure 3: Protocol transition and S4U2Self
The ticket returned to the server is a service ticket for the server concerned, but it contains the user's authorization data, and it is of a form capable of being used for the S4U2Proxy extension — that is, a ticket to be used for delegated credentialing on other servers.
Single Sign-on for Java now provides support for S4U2Self as well as S4U2Proxy, and for the use of both extensions in conjunction with each other.
How does Single Sign-on for Java work?
In Single Sign-on for Java Standard Edition, Single Sign-on for Java is implemented as a Java servlet filter.
On startup:
On initialization, the Single Sign-on for Java servlet filter uses the given configuration parameters to determine:
- the principal created for Single Sign-on for Java operations
- the credentials of the Single Sign-on for Java service principal, and
- various security options
- If the request is not yet authenticated:
Single Sign-on for Java performs the appropriate authentication for the mechanism specified (that is, in the 'Authorization' header of the request). It may attempt, in preferred order:
- SPNEGO:
The mechanism name given for this is “Negotiate”, and the mechanism token is a SPNEGO token.
SPNEGO handshake occurs; the SPNEGO token in the request is processed, and SPNEGO tokens may be returned to the browser in the “WWW-Authenticate” field of the response.
Eventually, if authentication succeeds, credentials are obtained.
The session state is updated with the obtained credentials and other user information. - NTLM (if configured):
The mechanism name is “NTLM” or “NEGOTIATE”, and its mechanism token is an NTLM token. For more information, see What is NTLM.
An NTLM handshake occurs, with messages exchanged between the client and server. These include negotiate, challenge and authenticate packets.
Once authentication occurs, a credential is obtained and stored in the session state for future authentication requests. - Basic fallback (if configured):
The mechanism name here is “Basic”, and its mechanism token consists of a base64-encoded username and password.
It works by converting username and password to a Kerberos principal and Kerberos password, requesting a TGT from the Active Directory domain controller’s in-built key distribution service.
It also requests a service ticket from the same source.
It stores credentials in the session state data for future authentication requests.
- SPNEGO:
- Once the request is authenticated, access to the specified resource is checked:
If no access policy has been set, access is automatically granted.
If an access policy has been set:
- Account information about the authenticated user is obtained (for example, group membership, last login, etc.).
-
If such information is not already available, it is obtained via LDAP queries on the domain controller or information in the service ticket.
If NTLM is used, all information is obtained via LDAP queries on the account of the user@domain. Otherwise, the service ticket contains Microsoft authorization data (a Privilege Attribute Certificate or PAC).
The PAC contains information such as last login time, group membership, etc. Active Directory may be queried via LDAP to convert information in the PAC to other forms (specifically, to convert a SID in the PAC to a name or vice-versa). - The access policy is examined to verify that the authenticated user has been granted access to the specified resource.
Example domain
Single Sign-on for Java supports complex Active Directory environments with multiple domains including both cross-realm and cross-forest scenarios.
However, the examples in this manual illustrate a single Active Directory domain called EXAMPLE.COM, whose DNS domain is example.com.
The example application servers in this domain have the hostnames appservhost1 (with fully qualified domain name appservhost1.example.com), appservhost2, etc.
Given this:
as a convention we will use vsj_appservhost1 as the name of the service account for Single Sign-on for Java running on the host appservhost1
HTTP/appservhost1.example.com is an SPN for appservhost1
Single Sign-on for Java's idm.principalAtRealm configuration parameter should be set to the value vsj_appservhost1@EXAMPLE.COM
The following figure shows points where these names apply.
Figure 4: Overview: Active Directory and Single Sign-on for Java configuration and terminology
The following figure illustrates a simplified version of the initial process involved when a client requests a URL from a service under Single Sign-on for Java, showing the use of naming conventions outlined above.
Figure 5: Access to a URL via Single Sign-on for Java (simplified)
