windows cross-platform authentication + WinSSO auth module on AM/OpenSSO

1. When the logged-on user requests a resource from the Web server, it sends the initial HTTP GET verb.

2. The Web server, running the SPNEGO Token Handler code, requires authentication and issues a 401 Access Denied, WWW-Authenticate: Negotiate response.

3. The client calls AcquireCredentialsHandle()and InitializeSecurityContext() with the SPN to build the Security Context that requests the session ticket from the TGS(KDC).

4. The TGS/KDC supplies the client with the necessary Kerberos Ticket (assuming the client is authorized) wrapped in a SPNEGO Token.

5. The client re-sends the HTTP GET request + the Negotiate SPNEGO Token in an Authorization: Negotiate base64(token) header.

6. The Web server's SPNEGO Token Handler code accepts and processes the token through GSS API, authenticates the user and responds with the requested URL.





Process flow for Windows Desktop SSO module in AM code



1. When the logged-on user (browser client) requests a protected resource from the Web server, it sends the initial HTTP GET verb.

2. The policy agent intercepts the request, sees SSO token in cookie is not present. It redirects it to the web server hosting Sun Access Manager which has WinSSO auth module code (SPNEGO Token Handler code).

3. The Web server, running the SPNEGO Token Handler code (Access Manager Windows desktop SSO auth module), requires authentication to access that resource. So Access Manager code on web server issues a 401 Access Denied, WWW-Authenticate: Negotiate response to the browser client.

4. The browser client calls AcquireCredentialsHandle()and InitializeSecurityContext() with the SPN to build the Security Context. In this process, SPNEGO capable browser requests the session ticket from the Ticket Granting Server (TGS - could be windows domain controller or unix kdc server). This direct interaction between browser and KDC will provide
a) Ticket Granting Ticket (TGT - if not already present)
b) Kerberos or NTLM ticket depending upon configuration. Note AM works only with Kerberos ticket. AM does not support NTLM ticket.
This is wrapped in a SPNEGO token which is presented to AM.

5. The TGS/KDC supplies the client (browser) with the necessary Kerberos Ticket (assuming the client is authorized) wrapped in a SPNEGO Token.

6. The client re-sends the HTTP GET request + the Negotiate SPNEGO Token in an Authorization: Negotiate base64(token) header to Windows Desktop SSO module of Access Manager running on Unix web server.

7. The SPNEGO Token Handler code in Windows Desktop SSO module of Access Manager running on Unix web server accepts and processes the token through GSS API, authenticates the user. After successful authentication, AM prepares SSO Token in a cookie.

8. AM sends back response to browser with HTTP code - 200. Now browser has SSO Token wrapped in a cookie.

9. Browser sends HTTP Get request to web server hosting policy agent so that it can handle the protected resource request.


References:
===========
MSDN Article-1
MSDN Article-2
MSDN Article-3
OpenSSO doc Article-1