Example of Policy Decision Process

When a user attempts to access content on a protected resource, many deployment variables are involved. For example, a firewall might or might not be present. Another example of a deployment variable concerns authentication levels. In a real-world deployment, different resources on a deployment container (such as an application or web server) might require different levels of authentication. These two examples hint at the complexity involved in providing an example of a policy decision process: the process varies greatly depending on the specifics of the deployment. Many other factors can affect the policy decision process, such as the IP address, time zone, and policy expiration time.

Each deployment variable can add a layer of complexity, which might affect how an agent reacts and how Access Manager reacts. This section provides a simple example of a policy decision process that highlights the role of an agent. Therefore, many of the detailed tasks and interactions, especially those processes that occur in Access Manager are left out. Do not expect the deployment represented in this example to match the deployment at your site. This is a generalized example that is applicable to both web and J2EE agents. Some of the basic steps in the policy decision process are depicted in Figure 1–1. The figure is followed by a written description of the process.

For this example, in order to focus on stages of the process most relevant to Policy Agent, certain conditions are assumed as follows:

The user is attempting to access a protected resource after having already accessed a protected resource on the same Domain Name Server (DNS) domain. When the user accessed the first protected resource, Access Manager started a session. The user's attempt to access a second resource, makes this user's session a single sign-on (SSO) session. Therefore, at this point, the following already occurred:

• The user attempted to access a protected resource through a browser (the first resource that the user attempts to access during this session).

• The browser request was intercepted by the agent.

• The browser was redirected to a login uniform resource locator (URL), which is the interface to Access Manager Authentication Service.

• After the user entered valid credentials, the service authenticated the credentials.

The following figure and the corresponding step descriptions demonstrate what occurs after a previously authenticated user attempts to access a second protected resource through a browser. This figure depicts user profiles and policy stored together. Note that these data types are often stored separately.

Figure 1–1 Policy Agent and the Policy Decision Process

1. The browser sends a request for the protected resource to the deployment container (such as a web or application server) protected by the agent.

2. The agent intercepts the request, checks for a session token embedded in a cookie, and validates the SSO token.

   As explained in preceding text, this example assumes that the user's credentials have already been authenticated. Though an SSO session such as this often would not require Policy Agent and Access Manager to contact each other during session validation, such contact is sometimes necessary and, therefore, is depicted in Figure 1–1.

3. The agent sends a request to Access Manager Policy Service for user access to the protected resource.

4. Access Manager replies with the policy decision.

5. The agent interprets the policy decision and allows or denies access.