Chapter 6 Models of the User Session and Single Sign-On Processes

This chapter traces events in a basic user session, a single sign-on session (SSO), a cross-domain single sign-on session (CDSSO), and session termination to give you an overview of the features and processes being invoked by OpenSSO Enterprise. It contains the following sections:

• Basic User Session

• Single Sign-On Session

• Cross-Domain Single Sign-On Session

• Session Termination

Basic User Session

The following sections describe the process behind a basic user session by tracing what happens when a user logs in to a resource protected by OpenSSO Enterprise. In these examples, the server which hosts an application is protected by a policy agent. The Basic User Session includes the following phases:

• Initial HTTP Request

• User Authentication

• Session Validation

• Policy Evaluation and Enforcement

• Logging the Results

Initial HTTP Request

When a user initiates a user session by using a browser to access and log in to a protected web-based application, the events illustrated in Figure 6–1 occur. The accompanying text describes the model.

Figure 6–1 Initial HTTP Request

1. The user’s browser sends an HTTP request to the protected resource.

2. The policy agent that protects the resource intercepts and inspects the user's request and finds no session token.

3. The policy agent issues a redirect to its configured authentication URL to begin the authentication process.

   In this example, the authentication URL it is set to the URL of the Distributed Authentication User Interface.

4. The browser, following the redirect, sends an HTTP request for authentication credentials to the Distributed Authentication User Interface.

5. The Session Service creates a new session (session data structure) and generates a session token (a randomly-generated string that identifies the session).

6. The Authentication Service sets the session token in a cookie.

The next part of the user session is User Authentication.

User Authentication

When the browser sends the HTTP request to the Distributed Authentication User Interface, the events illustrated in Figure 6–2 occur.

Figure 6–2 User Authentication

1. Using the parameters in the HTTP request from the browser (which includes the URL of the requested application), the Distributed Authentication User Interface contacts the OpenSSO Enterprise Authentication Service (which, in turn, communicates with the Session Service).

2. The Authentication Service determines what should be presented to the user based upon configuration data and retrieves the appropriate authentication module(s) and callback(s) information.

   For example, if configured to use LDAP Authentication, the Authentication Service determines that the LDAP Authentication login page should be displayed.

3. The collected information is passed to the Distributed Authentication User Interface using the Client SDK.

4. The Client Detection Service determines which protocol, such as HTML or WML, to use to display the login page.

5. The Distributed Authentication User Interface generates a dynamic presentation extraction page that contains the appropriate credentials request and callbacks information obtained from OpenSSO Enterprise.

   The session cookie will be included in this communication.

6. The user’s browser displays the login page.

7. The user enters information in the fields of the login page.

8. The browser sends the credentials in an HTTP POST to the Distributed Authentication User Interface.

9. The Distributed Authentication User Interface uses the Client SDK to pass the credentials to the Authentication Service.

10. The Authentication Service uses the appropriate authentication module to validate the user’s credentials.

    For example, if LDAP authentication is used, the LDAP authentication module verifies that the username and password provided exist in the LDAP directory.

11. Assuming authentication is successful, the Authentication Service activates the session by calling the appropriate methods in the Session Service.

    The Authentication Service stores information such as login time, Authentication Scheme, and Authentication Level in the session data structure.

12. Once the session is activated, the Session Service changes the state of the session token to valid.

13. The Distributed Authentication User Interface sends an HTTP response back to the browser with a validated SSOToken and location change.

14. The browser follows the redirect by sending another HTTP request to the original resource protected by a policy agent. This time, the request includes the valid session token created during the authentication process.

The next part of the user session is Session Validation.

Session Validation

After successful authentication, the user’s browser redirects the initial HTTP request to the server a second time for validation. The request now contains a session token in the same DNS domain as OpenSSO Enterprise. The events in Figure 6–3 illustrate this process.

Figure 6–3 Session Validation

1. The policy agent intercepts the second access request.

2. To determine the validity of the session token, the policy agent contacts the Naming Service to learn where the session token originated.

   The Naming Service allows clients to find the URL for internal OpenSSO Enterprise services. When contacted, the Naming Service decrypts the session token and returns the corresponding URL which can be used by other services to obtain information about the user session.

3. The policy agent, using the information provided by the Naming Service, makes a POST request to the Session Service to validate the included session token.

4. The Session Service receives the request and determines whether the session token is valid based on the following criteria:

   1. Has the user been authenticated?

   2. Does a session data structure associated with the session token exist?

5. If all criteria are met, the Session Service responds that the session token is valid.

   This assertion is coupled with supporting information about the user session itself.

6. The policy agent creates a Session Listener and registers it with the Session Service, enabling notification to be sent to the policy agent when a change in the session token state or validity occurs.

The next part of the user session is Policy Evaluation and Enforcement.

Policy Evaluation and Enforcement

After a session token has been validated, the policy agent determines if the user can be granted access to the server by evaluating its defined policies. Figure 6–4 illustrates this process.

Figure 6–4 Policy Evaluation

1. The policy agent sends a request to the Policy Service, asking for decisions regarding resources in its portion of the HTTP namespace.

   The request also includes additional environmental information. For example, IP address or DNS name could be included in the request because they might impact conditions set on a configuration policy.

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

   Policies are cached in OpenSSO Enterprise. If the policies have not been cached already, they are loaded from OpenSSO Enterprise.

3. If policies that apply to the request are found, the Policy Service checks if the user identified by the session token is a member of any of the Policy Subjects.

   1. If no policies that match the resource are found, the user will be denied access.

   2. If policies are found that match the resource, and the user is a valid subject, the Policy Service evaluates the conditions of each policy. For example, Is it the right time of day? or Are requests coming from the correct network?

      • If the conditions are met, the policy applies.

      • If the conditions are not met, the policy is skipped.

4. The Policy Service aggregates all policies that apply, encodes a final decision to grant or deny access, and responds to the policy agent.

The next part of the basic user session is Logging the Results.

Logging the Results

When the policy agent receives a decision from the Policy Service, the events illustrated in Figure 6–5 occur.

Figure 6–5 Logging the Policy Evaluation Results

1. The decision and session token are cached by the policy agent so subsequent requests can be checked using the cache (without contacting OpenSSO Enterprise).

   The cache will expire after a (configurable) interval has passed or upon explicit notification of a change in policy or session status.

2. The policy agent issues a logging request to the Logging Service.

3. The Logging Service logs the policy evaluation results to a flat file (which can be signed) or to a JDBC store, depending upon the log configuration.

4. The Logging Service notifies the policy agent of the new log.

5. The policy agent allows or denies the user access to the application.

   1. If the user is denied access, the policy agent displays an “access denied” page.

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

Assuming the browser displays the application interface, this basic user session is valid until it is terminated. See Session Termination for more information. While logged in, if the user attempts to log into another protected resource, the Single Sign-On Session begins.

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.

Cross-Domain Single Sign-On Session

CDSSO occurs when an authenticated user requests a protected resource on a server in a different DNS domain. The user in the previous sections, Basic User Session and Single Sign-On Session, for example, accessed applications in one DNS domain. In this scenario, the CDSSO Controller within OpenSSO Enterprise transfers the user’s session information from the initial domain, making it available to applications in a second domain.

The basic difference between the proprietary CDSSO and SAML v2 (as described in Federation Options) is that CDSSO uses a single authentication authority, a mechanism to move a cookie between multiple DNS domains. SAML v2, on the other hand, gives you the option of using multiple authentication authorities, with one authority asserting the identity of the user to the other.

1. The authenticated user’s browser sends an HTTP request to the application in a different DNS domain.

2. The policy agent intercepts the request and inspects it to determine if a session token exists for the domain in which the requested application exists. One of the following occurs:

   • If a session token is present, the policy agent validates the session.

   • If no session token is present, the policy agent (which is configured for CDSSO) will redirect the HTTP request to the CDSSO Controller.

     The CDSSO Controller uses Liberty Alliance Project protocols to transfer sessions so the relevant parameters are included in the redirect.

   In this example, no session token for the second domain is found.

3. The policy agent redirects the HTTP request to the CDSSO Controller.

4. The user’s browser allows the redirect to the CDSSO Controller.

   Recall that earlier in the user session the session token was set in a cookie in the first domain which is now part of the redirect.

5. The CDC Servlet (in the CDSSO Controller) receives the session token from the first domain, extracts the user's session information, formulates a Liberty POST profile response containing the information, and returns a response to the browser.

6. The user’s browser automatically submits the response to the policy agent in the second domain.

   The POST is based upon the Action and the Javascript included in the Body tags onLoad.

7. The policy agent in the second domain receives the response, extracts the session information, validates the session, and sets a session token in the cookie for the new DNS domain.

The process continues with Policy Evaluation and Enforcement and Logging the Results. Based on the policy outcome, the user is granted or denied access to the application.

1. If the user is denied access, the policy agent displays an “access denied” page.

2. If the user is granted access, the protected resource displays its access page. The new cookie can now be used by all agents in the new domain, and the session is valid until it is terminated.

Session Termination

A user session can be terminated in any of following ways:

• User Ends Session

• Administrator Ends Session

• OpenSSO Enterprise Enforces Timeout Rules

• Session Quota Constraints

User Ends Session

When a user explicitly logs out of OpenSSO Enterprise by clicking on a link to the Logout Service the following events occur:

1. The Logout Service receives the Logout request, and:

   1. Marks the user’s session as destroyed.

   2. Destroys the session.

   3. Returns a successful logout page to the user.

2. The Session Service notifies applications which are configured to interact with the session. In this case, each of the policy agents was configured for Session Notification, and each is sent a document instructing the agent that the session is now invalid.

3. The policy agents flush the session from the cache and the user session ends.

Administrator Ends Session

OpenSSO Enterprise administrators with appropriate permissions can terminate a user session at any time. When an administrator uses the Sessions tab in the OpenSSO Enterprise console to end a user’s session, the following events occur:

1. The Logout Service receives the Logout request, and:

   1. Marks the user’s session as destroyed.

   2. Destroys the session.

2. The Session Service notifies applications which are configured to interact with the session. In this case, each of the policy agents was configured for Session Notification, and each is sent a document instructing the agent that the session is now invalid.

3. The policy agents flush the session from cache and the user session ends.

OpenSSO Enterprise Enforces Timeout Rules

When a session timeout limit is reached, the Session Service:

1. Changes the session status to invalid.

2. Displays a time out message to the user.

3. Starts the timer for purge operation delay. (The default is 60 minutes.)

4. Purges or destroys the session when the purge operation delay time is reached.

5. Displays login page to the user if a session validation request comes in after the purge delay time is reached.

Session Quota Constraints

OpenSSO Enterprise allows administrators to constrain the amount of sessions one user can have. If the user has more sessions than the administrator will allow, one (or more) of the existing sessions can be destroyed.