Single Sign-On Session

SSO is always preceded by a basic user session in which a session is created and its session token is validated, and in which the user is authenticated. For detailed information, see Basic User Session.

SSO begins occurs when the authenticated user requests a protected resource on a second server in the same DNS domain. The following example describes an SSO session by tracing what happens when an authenticated user (from Basic User Session) accesses a second application, an expense reporting application. Session Service maintains user session information with input from all applications participating in the single sign-on. In this example, session service maintains information from the benefits administration and the expense reporting application. The following events occur.

Figure 2–5 Single Sign-On Session

1. The user attempts to access an expense reporting application.

   Both the expense reporting application and the benefits administration application from section Basic User Session are hosted by servers in the same domain.

2. The user’s browser sends An HTTP request to the expense reporting application. The request includes the user’s session token.

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

   A session token indicates the user is already authenticated. The user was authenticated when the user logged in to the benefits administration application, so authentication service is not required at this time. The SSO APIs retrieve the session data structure, which is known to SSO APIs as the SSOToken. The session token, or session ID, is known to SSO APIs as the SSOTokenID.

4. The policy agent determines the validity of the session.

   For detailed steps, see Session Validation.

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

6. If the SSOToken is not valid, then the user is redirected to the Authentication page.

7. If the SSOToken is valid, Session Service creates a Session Listener.

   A Session Listener allows notification to the policy agent when a change in the SSOToken state or validity occurs.

8. The policy agent sends a request to the Policy Service.

   The request asks for a decision regarding resources in the policy agent’s portion of the HTTP namespace.

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

10. If Policy Service does not find policy allowing access to the protected resource, the user is denied access. The following events occur:

    1. The Logging Service logs this denial of access.

    2. The policy agent issues a Forbidden message to the user.

       The user can then be redirected to an administrator-specified page indicating the user was denied access.

11. If Policy Service finds policy allowing access to the protected resource, the user is granted access to the protected resource.

    The SSO session is valid until it is terminated. Session Termination.

    While the user is still logged in, if the user decides to attempt to log in to another protected resource located in a different DNS domain, then CDSSO takes place.