The Policy agents work in association with the OpenSSO Policy component often called the Policy Decision Point (PDP). Before getting into the core discussions, let us explore a generic use case when someone needs to protect their application. In general, every business has resources and services that they want to protect, manage, and monitor. These businesses need to control the resource usage and access. Businesses control the resource use and access by setting up policies that administer who can do what to which resources, when, and how. OpenSSO can help businesses set up policies for controlling access to their resources, administer the policies, and authorize access to their resources based on their policies. The whole thing is orchestrated by using the Policy Evaluation component and a Policy Enforcement component.

Policy Service in the OpenSSO system provides the functionality of a Policy Administration Point (PAP) and Policy Decision Point (PDP). Like any other service this is defined using an XML file that conforms to sms.dtd. As a PAP, Policy Service implements the functionality to define Policies. A Policy in the OpenSSO system comprises Rule(s), Subject(s), Condition(s), Referral(s), and ResponseProvider(s). Subject, Condition, Referral, and ResponseProvider are interfaces and allow for different implementations, making the policy framework easily customizable and extensible. A Rule specifies the service type, resource, applicable actions, and applicable values for actions such as "allow" or "deny". Action could also take non-boolean values. A Subject identifies a collection of principles the policy applies to. Some examples are LDAP roles and groups. Condition specifies additional checks that need to be satisfied for the policy to be applicable. Some examples are time of access and the authentication level at which the user has authenticated. ResponseProvider provides some named attribute values that are included in policy decision. A Policy Enforcement Point (PEP) would typically pass these attributes to the applications it protects. The protected application could use these attributes to personalize the application behavior or use them to enforce fine-grained access control.

A Referral policy is like a normal policy except the evalution of the policy is delegated to the respecitve realm to which the referal is set to. It could be a sub-realm or peer realm.

As a PDP, Policy service implements the functionality to compute policy decisions. Policy service looks up applicable policies and evaluates policy decisions, which is applicable to a request by a principal on a resource, taking into account the environment parameters associated with the request. A policy decision wraps the applicable action values, policy advices, and response attributes. Policy advices are hints to PEP on some additional action that may be taken by PEP. One sample use of policy advice is to let PEP know the required authentication level to access a resource. A policy decision also has an "expires at" timestamp. A policy framework would not return an expired policy decision to clients. A PEP that caches a policy decision should not use the decision beyond its "expires at" timestamp.

The Policy Store is a logically centralized but possibly physically distributed store of the policy component that ensures integrity and consistency of the policies. As there can be several evaluators and policy administrators running simultaneously, they all need to cooperate well so that a change to the policy by one of the policy administrators is appropriately propagated in a timely manner to all the other policy administrators and evaluators. To enable this, the policy store supports change notifications. The policy store's out-of-the-box configuration uses the embedded store, which is based on OpenDS LDAP server. One can use the Oracle Directory Server Enterprise Edition as the policy store for a highly available environment.

OpenSSO Policy Agents are provided as add-on components, one for each container type that facilitate the protection of web-based network resources (enterprise applications and services). Policy Agents consume the public APIs and take care of the integration with the specific container such that their presence is largely transparent to the contained protected resources.

OpenSSO broadly provides two types of policy agents, Agents for:

Web agents control access to content on web servers and proxy servers. The content that web agents can protect include a multitude of services and web resources based on policies configured by an administrator. When a user points a browser to a URL deployed on a protected web or proxy server, the agent intercepts the request and validates the user's session token, if any exists. Otherwise a login page will be shown, prompting the user for credentials. Upon successful authentication based on the policy decision from the PDP, the individual is either allowed or denied access to the URL. These type of agents are simply a plugin NSAPI for iPlanet web/proxy servers or ISAPI filter for Microsoft IIS servers.

The J2EE agents are meant to protect the web applications that are deployed on Java EE-based Servlet containers and application servers such as the Oracle Weblogic Server. J2EE agents can help to enable role-to-principal mapping for protected Java EE applications with OpenSSO's principals. J2EE agents are implemented as a Servlet filter that need to be included in the web.xml of the application being protected along with an agent realm that is established at the installation time. The agents on the application servers such as IBM WebSphere involve more than just a Servlet filter as it does include the necessary code to set the agents realm and set the Java principal in the container by implementing the appropriate Trust Association Interceptor (TAI). A custom JAR file will be added by the OpenSSO policy agents in the container's classpath during the installation process.

One of the key differences between the Web and Java agent is the default protection scope. In the web server the document root is protected on installing the agent, whereas in the Java EE agents it is limited to the web application where the agent filter is included.

In this chapter, let us discuss the following:

You can use any operating system to perform the instructions given in this chapter, but for ease of use I have used the syntax that is applicable for the Linux operating system. Only Java agents are described in this chapter because installing and configuring web server agents is a trivial process.