Sun OpenSSO Enterprise Policy Agent 3.0 User's Guide for Web Agents

Chapter 2 Role of Web Agents in the Policy Agent 3.0 Release

This guide focuses on web agents. This chapter provides more information about how web agents function generally.

Note –

You can gain a stronger understanding of web agents by reviewing the appendix Appendix A, Comparing Web Agents and J2EE Agents in Policy Agent 3.0. The comparison provided in that appendix is helpful in that it provides an abundance of information about general Policy Agent functionality.

Uses of Web Agents

Web agents function with OpenSSO Enterprise to protect content on web servers and web proxy servers from unauthorized intrusions. They control access to services and web resources based on the policies configured by an administrator. Web agents perform these tasks while providing single sign-on (SSO) and, in most cases, cross domain single sign-on (CDSSO) capabilities as well as URL protection.

Web agents are installed on deployment containers for a variety of reasons. Here are three examples:

In each of these situations, a system administrator must set up policies that allow or deny users access to content on a deployment container. For information on setting policies and for assigning roles and policies to users, see the Sun Java System Access Manager 7.1 Administration Guide.

How Web Agents Work

When a user points a browser to a particular URL on a protected deployment container, a variety of interactions take place as explained in the following numbered list. See the terminology list immediately following this numbered list for a description of terms.

  1. The web agent intercepts the request and checks information in the request against not-enforced lists. If specific criteria are met, the authentication process is bypassed and access is granted to the resource.

  2. If authentication is required, the web agent validates the existing authentication credentials. If the existing authentication level is insufficient, the appropriate OpenSSO Enterprise Authentication Service will present a login page. The login page prompts the user for credentials such as username and password.

  3. The authentication service verifies that the user credentials are valid. For example, the default LDAP authentication service verifies that the username and password are stored in the user data store. You might use other authentication modules such as RADIUS and Certificate modules.

  4. If the user’s credentials are properly authenticated, the web agent checks if the users is authorized to access the resource.

  5. Based on the aggregate of all policies assigned to the user, the individual is either allowed or denied access to the URL.

Terminology: How Web Agents Work

Authentication Level

The ability to access resources can be divided into levels. Therefore, different resources on a deployment container (such as a web server or proxy server) might require different levels of authentication


OpenSSO Enterprise is made of many components. A service is a certain type of component that performs specific tasks. Some of the OpenSSO Enterprise services available are Authentication Service, Session Service, Logging Service, and Policy Service.

Authentication Module

An authentication interface, also referred to as an authentication module, is used to authenticate a user on OpenSSO Enterprise.


A policy defines rules that specify access privileges to protected resources on a deployment container, such as a web server.

Policy Decision Process for Web Agents

The figure that follows is a flow chart of the policy decision process for web agents. This figure illustrates how a single request is processed. The chart is useful in that it demonstrates to some degree how web agents function.

The chart illustrates possible scenarios that can take place when an end user makes a request for a resource. Therefore, the end user points a browser to a URL. That URL is a resource, such as a JPEG image, HTML page, JSP page, etc. When a resource is under the sphere of influence of the web agent, the agent intervenes to varying degrees, depending on the specifics of the situation, checks the request, and takes the appropriate action, which culminates with the user either being allowed or denied access to the resource. The chart reflects the potential paths a request makes before finally being allowed or denied.

You can see how this web agent-specific flow chart compares to the J2EE agent flow chart as illustrated in Examples of the Policy Decision Process by Agent Type. The comparison gives a sense of how the two agent types differ in how they handle requests for resources.

Figure 2–1 Policy Agent and the Policy Decision Process

This figure is a flow chart of the policy decision process
for a web agent.