Single Sign-On Session

SSO is always preceded by a basic user session in which a session is created, its session token is validated, the user is authenticated, and access is allowed. SSO begins when the authenticated user requests a protected resource on a second server in the same DNS domain. The following process describes an SSO session by tracking what happens when an authenticated user accesses a second application in the same DNS domain as the first application. Because the Session Service maintains user session information with input from all applications participating in an SSO session, in this example, it maintains information from the application the user was granted access to in Basic User Session.

Figure 6–6 Single Sign-On Session

1. The user attempts to access a second application hosted on a server in the same domain as the first application to which authentication was successful.

2. The user’s browser sends an HTTP request to the second application that includes the user’s session token.

3. The policy agent intercepts the request and inspects it to determine whether a session token exists.

   A session token indicates the user is already authenticated. Since the user was authenticated, the Authentication Service is not required at this time. The Session Service API retrieve the session data using the session token identifier imbedded in the cookie.

4. The policy agent sends the session token identifier to the OpenSSO Enterprise Session Service to determine whether the session is valid or not.

   For detailed steps, see Session Validation.

5. The Session Service sends a reply to the policy agent indicating whether the session is valid.

   • If the session is not valid, the user is redirected to the Authentication page.

   • If the session is valid, the Session Service creates a Session Listener.

6. As the session is valid, the Session Service creates a Session Listener.

   A Session Listener sends notification to the policy agent when a change in the session state occurs.

7. The policy agent sends a request for a decision regarding resources in it’s portion of the HTTP namespace to the Policy Service.

8. The Policy Service checks for policies that apply to the request.

9. The Policy Service sends the policy evaluation response (either Access Denied or Access Granted.) to the policy agent.

   • If Policy Service does not find policy allowing access to the protected resource, the user is denied access and the Logging Service logs a denial of access. The user may be redirected to a specified page indicating that access was denied if configured as such by the administrator.

   • If the Policy Service finds policy allowing access to the protected resource, the user is granted access and the session is valid until terminated.

10. The policy agent sends a reply to the user indicating whether the user is granted the access.

    • If the user is denied access, the policy agent displays an Access Denied page.

    • If the user is granted access, the protected resource displays its access page.

Assuming the Policy Service finds policy allowing access to the protected resource, the user is granted access and the SSO session is valid until terminated. See Session Termination. While still logged in, if the user attempts to log in to another protected resource located in a different DNS domain, the Cross-Domain Single Sign-On Session begins.