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 Access Manager. In these examples, the server which hosts an application is protected by an Access Manager policy agent. The Basic User Session includes the following phases:

• Initial HTTP Request

• User Authentication

• Session Validation

• Policy Evaluation and Enforcement

• Logging Results

Initial HTTP Request

When a user initiates a user session by using a browser to log in to a web-based application, the events in the following illustration occur. The accompanying text describes the process.

Figure 2–1 Initial HTTP Request

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

2. The policy agent inspects the user’s request and finds no session token.

3. The policy agent contacts the configured authentication URL.

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

4. The browser sends a GET request to the Distributed Authentication User Interface.

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

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 a GET request to the Distributed Authentication User Interface, the events in the following illustration occur. The accompanying text describes the process.

1. Using the parameters in the GET request, the Distributed Authentication User Interface contacts the Authentication Service installed on the Access Manager server.

2. The Authentication Service determines the appropriate authentication module to use based upon Access Manager configuration and the request parameters passed by the Distributed Authentication User Interface using the Authentication client APIs.

   For example, if Access Manager is configured to use the LDAP Authentication type of module, the Authentication Service determines that the LDAP Authentication login page will be used.

3. The Authentication Service determines which presentation callbacks should be presented, and sends to the Distributed Authentication User Interface all necessary credentials, requirements, and callbacks for use by the presentation framework layer.

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 returns to the Web browser a dynamic presentation extraction page along with the session cookie.

   The presentation extraction page contains the appropriate credentials request and callbacks info obtained from the Access Manager server.

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

   The user enters information in the Username and Password fields of the login page.

7. The browser replies to the Distributed Authentication User Interface with a POST that contains the required credentials.

8. The Distributed Authentication User Interface uses the Authentication client APIs to pass credentials to the Access Manager server.

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

   For example, if the LDAP authentication module type is used, the Authentication Service verifies that the username and password provided exist in the LDAP directory. Other authentication module types have different requirements.

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

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

12. The Distributed Authentication User Interface replies to the protected resource with an SSOToken in a set-cookie header.

13. Now, the browser makes another request to the original resource protected by a policy agent.

    This time, the request includes a valid session token, created during the authentication process.

The next part of the user session is Session Validation.

Session Validation

After authentication, when the user’s browser redirects the initial HTTP request to the server for a second time, the events in the following illustration occur. The accompanying text describes the process.

Figure 2–2 Session Validation

1. The policy agent intercepts the second access request.

   The request now contains a session token in the same DNS domain as Access Manager.

2. The policy agent determines the validity of the session token.

   1. The policy agent contacts the Naming Service to learn where the session token originated.

      The Naming Service allows clients to find the service URL for the internal services used by Access Manager. This information can then be used for communication regarding a session.

   2. The Naming Service decrypts the session token and returns the corresponding URLs . The URLs will 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 the Session Listener with the Session Service. This enables notification 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.

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 it's defined policies. The following illustration and accompanying text describes the process.

Figure 2–3 Policy Evaluation

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

   The request asks for decisions regarding resources in the policy agent’s 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 Access Manager. If the policies have not been cached already, then the policies are loaded from the Access Manager information tree in the Identity Repository.

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 is denied access. Skip to step 5.

   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 with the appropriate decision.

The next part of the user session is logging the policy evaluation results.

Logging Results

When the policy agent receives an allow decision from the Policy Service, the events in the following illustration occur. The accompanying text describes the process.

Figure 2–4 Logging the Policy Evaluation Results

1. The allow decision is cached in the policy agent, along with the session token, so that subsequent requests can be checked using the cache.

   It is no longer necessary for the policy agent to contact Access Manager. The cache will expire after an interval has passed or upon an explicit notification of change in policy or session status. The interval is configurable.

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.

While the user is still logged in, if he attempts to log into another protected resource, the Single Sign-On session begins.