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 example describes an SSO session by tracing 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. We will assume the application previously accessed was a corporate benefits administration application. For this SSO session, the user is attempting access to an expense reporting application.

Figure 2–5 Single Sign-On Session

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

   Both the expense reporting application and the corporate benefits administration application are hosted on 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. Since the user was authenticated when the user logged in to the corporate benefits administration application, the Authentication Service is not required at this time. The SSO APIs retrieve the session data structure using the session token imbedded in the cookie. The session data structure is referred to as the SSOToken by the SSO APIs. The session token is referred to 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.

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

   • If the SSOToken is valid, the 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.

6. 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.

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

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

     1. The Logging Service logs a 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.

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

While still logged in, if the user decides to attempt to log in to another protected resource located in a different DNS domain, Cross-Domain Single Sign-On takes place.