Sun Java System Access Manager 7 2005Q4 Technical Overview

Basic User Session

When Access Manager policy agents are implemented, by default all HTTP requests are implicitly denied unless explicitly allowed by the presence of two things: 1) a valid session, and 2) policy allowing access. You can modify the default configuration so that Access Manger implicitly allows access unless explicitly denied. For detailed information on configuring Session Service, see The Current Sessions Interface in Sun Java System Access Manager 7 2005Q4 Administration Guide.

The following sections describe 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

A user initiates a user session by using a browser to log in to a web—based application.

Figure 2–1 Initial HTTP Request

Details are explained in the following body text.

The following events occur:

The user’s browser sends an HTTP request to the protected resource.
The policy agent inspects the user’s request, and no session token is found.
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.
The browser sends a GET request to the Distributed Authentication User Interface.
The Session Service creates a new session, or data structure, and generates a session token. The session token is a randomly-generated string that represents the user.
Authentication Service sets the session data structure 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 following events occur.

Using the parameters in the GET request, the Distributed Authentication User Interface contacts the Authentication Service installed on the Access Manager Server.
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 through 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.
Authentication Service determines which presentation callbacks should be presented, and sends to the Distributed Authentication User Interface all necessary credentials, requirements, and callbacks to be in used the presentation framework layer.
Client Detection Service determines which protocol, such as HTML or WML, to use to display the login page.
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.
The user’s browser displays the login page.

The user enters information in the Username and Password fields of the login page.
The browser replies to the Distributed Authentication User Interface with a POST that contains the required credentials.
The Distributed Authentication User Interface uses the Authentication client APIs to pass credentials to the Access Manager Server.
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, Authentication Service verifies that the username and password provided exist in the LDAP directory. Other authentication module types have different requirements.
When authentication is successful, Authentication Service activates the session by calling the appropriate methods in the Session Service.

Authentication Service stores information such as Login time, Authentication Scheme, and Authentication Level in the session data structure.
Once the session is activated, Session Service changes the state of the session token to valid.
The Distributed Authentication User Interface replies to the protected resource with an SSOToken in a set-cookie header.
The browser makes a request to the originally requested resource protected by an Agent.

This time, the request includes the valid session data structure and session token that were 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 mail server for a second time, the following events occur.

The policy agent intercepts the second access request.

The request now contains a session token in the same DNS domain as Access Manager.
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.
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.
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 and session token exist?
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.
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.

Figure 2–2 Session Validation

Details are provided in the following body text.

Policy Evaluation

Once a session token has been validated, the policy agent determines if the user can be granted access to the mail server. The following events occur.

Figure 2–3 Policy Evaluation

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.
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.
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, then Policy Service evaluates conditions of each policy. For example, Is it the right time of day? Are requests coming from the correct network?
  - If conditions are met, the policy applies.
  - If conditions are not met, the policy is skipped.
Policy service aggregates all policies that apply, and encodes a final decision to grant or deny access.
Policy Services responds to the policy agent with the appropriate decision.
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.

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

Results Logging

When the policy agent receives an allow decision from the Policy Service, the following events occur.

Figure 2–4 Logging the Policy Evaluation Results

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.
The policy agent issues a logging request to the Logging Service.
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.
The Logging Service notifies the policy agent of the new log.
The policy agent allows the user access to the application.

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, then the Single Sign-On session begins.