A Generalized Example of the Policy Decision Process

When a user attempts to access content on a protected resource, many deployment variables are involved. For example, firewalls might be present or load balancers might be involved. From a high level, the two agent types (J2EE agents and web agents) handle these deployments in the same manner. The following reference presents figures that demonstrate how web agents and J2EE agents have the same role in a complex OpenSSO Enterprise deployments: Part I, About This Deployment, in Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0.

Therefore, J2EE agents and web agents do not differ in the general role they play in an OpenSSO Enterprise deployment. However, at the policy decision level, the differences between the two agent types are more easily observed, and components such as firewalls and load balancers can add complexity to the policy decision process. Therefore, for the basic example provided in this section about the policy decision process, such complex details are not included.

Another example of a deployment variable concerns authentication levels. In a real-world deployment, different resources on a deployment container (such as an application server or web server) might require different levels of authentication. Suffice to say a great deal of complexity is involved in providing a generic example of a policy decision process, especially one that applies equally to J2EE agents and web agents. For one, 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 OpenSSO Enterprise 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 OpenSSO Enterprise 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 agents and J2EE agents. Some of the basic steps in the policy decision process are depicted in Figure A–2. The figure is followed by a written description of the process. Notice that the figure illustrates the policy decision process in terms of the components the decision passes through. To see the policy decision process in a flow chart view, see Figure A–3 for the J2EE agent view and Figure A–4 for the web agent view.

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, OpenSSO Enterprise 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 OpenSSO Enterprise 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 A–2 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 session via OpenSSO Enterprise session service.

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

4. OpenSSO Enterprise replies with the policy decision.

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