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.