Silent Single Sign-On (SSO) refers to the exchange of authentication tokens without prompting the user to enter credentials. The client simply uses the Windows credentials already entered to log into to the workstation or device.
This is more secure and convenient compared to other SSO solutions that require users to enter credentials when their session expires.
The exchange of tokens is implemented with SPNEGO (also known as "Negotiate") which is a binary encoded wrapper around tokens of other mechanisms with associated logic. In practice the underlying mechanisms are Kerberos and NTLM.
The SPNEGO over HTTP "handshake" looks something like the following:
C: GET /some/resource S: 401 Unauthorized WWW-Authenticate: Negotiate C: GET /some/resource Authorization: Negotiate oYIAvTClMxIBa... Base64 encoded SPNEGO token S: 200 OK
Note: If the client selects the NTLM mechanism, an additional 401 + GET with tokens are exchanged.
When challenged by the first 401 Unauthorized, the client checks that the "Local intranet" zone settings allow Silent SSO to the target URL. If not, the browser will prompt the user to enter their AD DS credentials.
The browser will compose a Service Principal Name (SPN) by simply prepending HTTP/ to the hostname in the URL.
For example, if the URL were:
https://hrt.sebank.corp:8443/some/resource
the corresponding SPN would be:
HTTP/hrt.sebank.corp
An SPN is just a name that functions as an alias for an account. It also functions to exclude requests that do not target the correct scheme and host. SPNs are set into the servicePrincipalName attribute of an AD DS account (the HSS Computer account in this case).
The client will try to request a Kerberos ticket for the SPN from the KDC of the workstation or device on TCP port 88.
If the client cannot communicate with a suitable KDC, it will fallback to NTLM.
If the KDC cannot find an account with the specified SPN, an error will be returned and the client will fallback to NTLM.
If the time on the client and KDC is not synced within 5 minutes, the client will fallback to NTLM.
The browser will encode the Kerberos ticket into a Base64 encoded SPNEGO token.
The browser will then re-submit the HTTP request with the SPNEGO token set into the Authorization header as shown above.
The HttpSecurityService will decode the Base64 Authorization header token and pass it to the SPNEGO / Kerberos / NTLM code.
Assuming Kerberos was negotiated, Jespa will decode the token, extract the SPN, use it to locate the correct Kerberos base key, and attempt to use that key to decrypt the Kerberos ticket.
If the ticket is successfully decrypted but the timestamp encoded within it is not within 5 minutes of the current time on the Jespa host, a KRB_AP_ERR_SKEW: Clock skew too great exception will be logged and the request will fail with 401 Unauthorized.
If additional checks performed by the HttpSecurityService pass (like TLS channel bindings), the HTTP request is successful and the requested resource is invoked / returned.
If any of these steps are not successful, the request fails with 401 Unauthorized. The returned page content also contains a JavaScript redirect to the fallback.location (if set).