test

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

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

This guide focuses on J2EE agents. Therefore, this section provides more information about how J2EE agents function generally.

J2EE agents enable application containers to enforce authentication and authorization using OpenSSO Enterprise services. To ensure secure client access to hosted J2EE applications, J2EE agents enforce the following:

This chapter provides information about J2EE agents for the 3.0 release of Policy Agent as follows:

Uses of J2EE Agents

J2EE agents can protect a variety of hosted J2EE applications, which can in turn require policy implementation that varies greatly from application to application. The security infrastructure of J2EE provides declarative as well as programmatic security that is platform-independent and is supported by all the J2EE-compliant deployment containers. For details on how to use the declarative and programmatic security of the J2EE platform, refer to J2EE documentation, available at http://java.sun.com/j2ee.

The way J2EE agents function in the 3.0 release can be quite different when compared to previous releases because of the option of storing the configuration in the central data repository of the OpenSSO Enterprise server. However the purpose of J2EE agents has not changed significantly. The agent configurations are easier to manage, but the basic purpose is the same.

J2EE agents help enable role-to-principal mapping for protected J2EE applications with OpenSSO Enterprise principals. Thus at runtime, when a J2EE policy is evaluated, it is done against the information available in OpenSSO Enterprise. Using this functionality, administrators can configure their hosted J2EE applications to be protected by the agent, which provides real security services and also other key features such as single sign-on. Apart from enabling the J2EE security for hosted applications, the J2EE agents also provide complete support for OpenSSO Enterprise based URL policies for enforcing access control over web resources hosted in the deployment container.

The following examples demonstrate how the J2EE agents can be put to use.

J2EE Agents and an Online Auction Application

Consider a web-based application that facilitates the auction of various kinds of merchandise between interested parties. A simple implementation for such an application will require the users to be in one of three abstract roles, namely Buyer, Seller, or Administrator. Buyers in this application will have access to web pages that display the listed auction items, whereas the Sellers may have access to web pages that allow them to list their merchandise for new auctions. The Administrators may have access to yet another set of web pages that allow them to finalize or cancel existing auctions in whatever state they may be in. Using the deployment descriptors, the application developer can express this intent by protecting such components using abstract security role names.

These abstract role names in turn can be mapped to real principals in a J2EE agent. For example, the role Buyer may be mapped to an OpenSSO Enterprise role called Bidder, the role Seller to an OpenSSO Enterprise role called Vendor, and the role Administrator to an OpenSSO Enterprise role called Admin. The abstract role names used by the application developer can be used to protect the necessary web pages and any specialized Enterprise JavaBeans (EJB) components from unauthorized access by using declarative as well as programmatic security. Once this application is deployed and configured, the agent will ensure that only the authorized personnel get access to these protected resources.

For example, access to the pages meant for Sellers to list their merchandise for auctions will be granted to user Deepak only if this user belongs to the OpenSSO Enterprise role called Vendor. Similarly, users Scott and Gina can place bids on this listed item only if they belong to the role called Bidder. Once the auction period expires, the auction can be finalized by user Krishnendu only if he is in the role called Admin.

J2EE Agents and a Web-Based Commerce Application

A web-based commerce application may have a variety of specialized EJB components that offer a spectrum of services to clients. For instance, there could be a specialized component that enables the creation of purchase orders. Similarly, there could be a specialized component that allows the approval of purchase orders. While such components provide the basic business services for the application to function, the very nature of tasks that they accomplish requires a security policy to enforce appropriate use of such services. Using the deployment descriptors, the application vendor or developer can express this intent by protecting such components using abstract security role names. For example, a developer can create a role called Buyer to protect the component that allows the creation of a purchase order and a role called Approver to protect the component that enables the approval of a purchase order. While these roles convey the intent of an application developer to enforce such security policies, they will not be useful unless these abstract role names are mapped to real life principals such as actual users or actual roles that reside in OpenSSO Enterprise.

The J2EE agent enables the container to enforce such a runtime linkage of abstract security roles to real life principals. Once the agent is installed and configured, the application security roles can be mapped to real principals. For example, the role Buyer is mapped to an OpenSSO Enterprise role called Staff, and the role Approver is mapped to an OpenSSO Enterprise role called Manager. Thus when user Arvind tries to access the application's protected resources to create a purchase order, the agent allows this access only if this user is a member of the mapped role Staff. Similarly, a user Jamie may wish to approve this purchase order, which will be allowed by the agent only if this user is a member of the mapped role Manager.

J2EE Agents and a Content-Based Web Application

A content-based web application can offer pay per-view services. The application may be partitioned into two domains: the public domain that is accessible to anonymous users, and the private domain that is accessible only to the subscribers of this particular service. Furthermore, the protected domain of this application can also be subject to strict conditions based on how the user has authenticated, the time of day, IP address-based conditions and so on. Using OpenSSO Enterprise based URL policies for web resources, an administrator specifies such complex policies for the application resources, which are evaluated by the agent in order to ensure that access to these resources is granted only when all conditions are satisfied. An administrator can set policies that govern access to these resources at any level of granularity, such as that for a single user or for an entire organization. For example, one such policy may govern access to certain resources in such a manner that the user must belong to a particular LDAP Group called Customer and that the time of the day be between 9:00 am and 5:00 p.m. Thus, if user Rajeev attempts to access this resource, the agent allows access only if this user is a member of the LDAP Group Customer, and if the time of day is between 9:00 am and 5:00 p.m.

How J2EE Agents Work

All J2EE agents communicate with OpenSSO Enterprise by XML over HTTP. J2EE agents contain two main components: the agent realm and the agent filter. Together, these two components affect the operation of the deployment container and the behavior of protected applications on the deployment container.

Policy Decision Process for J2EE Agents

The figure that follows is a flow chart of the policy decision process for J2EE agents. This figure illustrates how a single request is processed. The chart is useful in that it demonstrates to some degree how J2EE 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 J2EE 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. Moreover the chart illustrates how the filter mode is involved in the resource-request process.

You can see how this J2EE agent-specific flow chart compares to the web 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 J2EE Agents and the Policy Decision Process

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

Using the J2EE Agent Sample Application in Policy Agent 3.0

Deploy, and interact with the sample application included with Policy Agent 3.0. Interacting with the sample application is perhaps the best way available to you to learn how J2EE agents work.

The sample application is deployed at URI/agentsample. The sample application demonstrates agent configuration options and features. With this application, you can view agent configuration examples and you can test if an agent was deployed successfully. To learn more about this application, read about the sampleapp directory explained in the list following Table 3–1. Moreover, the sampleapp directory includes a readme.txt explaining how to build and deploy the sample application. When you unpack the J2EE agent distribution, a sample application named agentsample.ear is created for you. The full path to this application is as follows:

PolicyAgent-base/sampleapp/dist/agentsample.ear