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.