|
|
The chapter describes methods of integrating Oracle Entitlements Server with application environments under different deployment models.
Oracle Entitlements Server supports a number of integration points to interact with other applications and environments in your enterprise. The runtime API is the interface to the SSMs and can be invoked via Java or Web Services calls. Java clients have the option of calling the SSM which is embedded directly inside their runtime or making remote calls to the RMI or Web Services SSM via a proxy. The choice can be made outside of their application via configuration and Java clients can switch protocols without any recoding."
The management APIs can be used to create users, groups, and roles, define access or role-mapping policies, or distribute policies to the SSMs. The management APIs can be invoked either through Java or Web Services calls. Finally, Oracle Entitlements Server supports a wide variety of directories and relational databases for either authenticating users or retrieving user attribute information.
Out-of-box SSMs plug directly into the application container and automatically intercept access requests and enforce access decisions with no changes to the application. These out-of-box SSMs are available for WebLogic Platform products and Web Servers. They also provide integration with the Oracle Enterprise Repository product for policy versioning and workflow.
The following out-of-box SSMs are provided in Oracle Entitlements Server 10g Release 1.0.4.3:
For custom application objects, the developer creates explicit calls to Oracle Entitlements Server in the application code in place of application-specific access control logic. Figure 4-1 illustrates how this is typically done.
Let’s look at this example in some detail. At the top left we have the application – the user is trying to transfer $1000 from one account to another. The application needs to check whether the user is authorized to make that transfer.
In the top right corner we have depicted the administration console and the policy associated with the transaction. In this case the policy is written to Deny access to the transaction resources if the request amount is greater than the limit imposed by the bank on that account. Note that the policy decision is completely data driven – the transfer will be granted or denied based on comparing the value of a user attribute to the account limit. On the bottom left, we see the Java that makes a call to the Client API. The call is straight forward – the user is trying to access a resource (transaction) within a specific context (amount). Finally on the bottom right side – the users account limit will be compared to the requested transfer amount. In this example the user’s attribute values are stored in the entitlements system. However, that data could be stored in any external system (e.g. RDBMS, LDAP, or Web Service).
Note also that the Java application could be making calls to the Java SSM embedded within its runtime or remote calls to the Web Service or RMI SSMs using the same API.
For clarity we have shown how an entitlements system might be integrated programmatically with the application. It is also possible to encapsulate the client integration (depending on programming model) to minimize the amount of integration code and to standardize the integration with the application.
For presentation elements, a tag library is provided for JSP developers. The tag library allows you to protect access to page level elements like buttons, menu items, tabs, links, or any other data on the page. In the example shown in Figure 4-2, the JSP developer wants to show the private information only to those authorized to see it. The IsAccessAllowed tag in the JSP code initiates a call to the policy engine. The grant policy shown below applies to the resource called /examplewebapp/private as identified by the tag. All users in the group called Private will be granted access and will see the information in the private table. All others will be denied and the private data table will not be displayed.
Oracle Entitlements Server also provides users of WebLogic Workshop a way to annotate java objects to indicate that they are to be protected. The annotation indicates the name of the resource, the action on that resource, and any security related attributes of the resource. The Workshop project can be inspected and its resources, the action, and any resource attributes can be imported into OES. Then, from the Entitlements Administration Application, the security administrator can create the desired role or access policies for that resource. This allows the developer and security architect to work together. In this model, the developer indicates what needs to be protected and the security architect defines how that object will be protected.
While developers and third parties may use the Security Service Provider Interfaces (SSPIs) to develop custom security providers, the product comes with a range of out-of-box providers that provide authentication, authorization, identity assertion, credential mapping, and auditing with leading vendors.
OES provides the following out-of-box attribute retrievers that are used by ASI Authorization and ASI Role Mapping providers to retrieve attributes for use in policies:
— RDBMSAttribute Retriever
— LDAPAttribute Retriever
— SDOAttribute Retriever
— ALESIdentity Attribute Retriever
— Custom Attribute Retriever
If the out-of-box attribute retrievers do not meet your needs, you may develop your own and manage it from the console.
Two main deployment models are supported. The two models differ in the placement of the Policy Decision Point (PDP). The SSM serves as the PDP. In the distributed model the PDP is embedded in the application container and all security services are fully distributed. In the centralized model, client applications make calls to a central PDP via RMI or SOAP calls. The central PDP makes the access decision (by evaluating policy) and returns an authorization result to the client. These two models are not mutually exclusive. Any combination of the two is possible.
A typical distributed deployment is shown in Figure 4-3. In the distributed model, SSMs plug into the application container. Out-of-box SSMs are provided for WebLogic products, popular Web Servers, and for Java. In the distributed model, the SSM acts as both the Policy Decision Point and the Policy Enforcement Point.
The WebLogic SSM protects J2EE objects in WebLogic Server such as JSPs, EJBs, Web Services and POJO’s. It also protects portal objects in WebLogic Portal such as books, pages, portlets, and desktops. The Java SSM exposes runtime services through a Java API and can be used to secure applications in other Java environments.
Figure 4-4 shows a typical centralized deployment. Here the SSM is hosted on a dedicated server and receives authorization requests from multiple clients. On the clients, SSM proxies provide local security services, including authorization caching, and communicate with the central SSM using RMI or SOAP as the transport protocol.
Oracle Entitlements Server was designed to be highly scalable. This is accomplished in a number of ways. First, the policy decision points (the SSMs) can be fully distributed. Policies are pushed to the SSMs from the Administration Server. From that point forward, all decisions are made and cached locally at the SSM (no network calls to a central server). Second, the policy model supports and encourages the use of a small number of policies that can make use of a rich set of user entitlement information. This minimizes the set of policies to be managed. Using a small set of data driven policies also aids in compliance. Finally, Oracle Entitlements Server has a scalable model for entitlement retrieval. Static entitlements are retrieved once (at authentication time). Dynamic attributes are retrieved at authorization time and cached during the user’s session. The cache is fully configurable by the user. You can also write custom attribute retrievers that can implement a caching scheme specific for your application environment.
|