|Oracle® Fusion Middleware Administrator's Guide for Oracle Entitlements Server
11g Release 1 (11.1.1)
Part Number E14096-05
|PDF · Mobi · ePub|
This chapter contains an overview of the features and architecture of Oracle Entitlements Server 11gR1. It contains the following sections:
Access control is a system used to grant or deny access to an enterprise's information, systems or resources. For the purposes of this documentation, the entity that is being protected is referred to as the protected resource while the entity to which access is granted or denied is referred to as the subject (most often a real person). A policy matches a subject with a set of operations that determine what the subject is allowed to see and do within the protected resource. The protected operations are dependent on the type of resource. For example, the protected operations attached to a text file (read, modify, delete) are different from those that can be attached to a banking application (view account, transfer money, modify profile).
Access control assures that only authorized subjects can access protected resources thus preventing the resources from unauthorized or inadvertent modification. Authorization of a subject typically occurs after authentication. In general, an access control system may comprise two types of authorization:
Coarse grained authorization is perimeter authorization that uses technology principally focused on “keeping the bad guys out.” Generally, it is performed by interceptors outside the application making the authorization call. It takes into account a URL and the policies regarding the subject requester.
Fine grained authorization is more detailed, and primarily controlled by the application making the authorization call. It takes into account the URL of the protected resource and its configured policies as well as information that may include resource-specific or user attributes and the context of the request. For example, granting an employee access to a portal during normal business hours and denying this access during the weekend hours would call for fine grained authorization.
Thus, an access control system must support a policy model that is easy to administer yet allows for complex sets of conditions under which access can be granted (or denied). Oracle Entitlements Server is a product that provides centralized policy management with centralized or distributed access control enforcement for all types of resources including software components and application business objects.
Oracle Entitlements Server is a fine-grained authorization product that allows an organization to protect its resources by defining and managing policies that control access to, and usage of, these resources. Access privileges are defined in a policy by specifying who can do what to which resource, when it can be done, and how. The policy can enforce controls on all types of resources including software components (URLs, Java Server Pages, Enterprise JavaBeans, methods, servlets and the like used to construct an application) and business objects (representations of user accounts, personal profiles and contracts such as bank accounts in a banking application, patient records in a health care application, or anything used to define a business relationship).
Oracle Entitlements Server supports the creation of role policies and access control policies. Role policies are used to define constraints regarding which users are assigned roles. (This is accomplished directly or indirectly using enterprise groups.) Access control policies define access to the software components and business objects. The following sections contain information on the previous releases of Oracle Entitlements Server and the features developed for this release, Oracle Entitlements Server 11gR1.
Oracle Entitlements Server 11gR1 represents a consolidation of Oracle Platform Security Services with Oracle Entitlements Server 10g (formerly BEA AquaLogic Enterprise Security). While Oracle Platform Security Services is a Java Authentication and Authorization Services (JAAS) security provider that offers coarse-grained authorization, Oracle Entitlements Server 11gR1 is an end-to-end enterprise solution that includes multiple technologies including Java Standard Edition (SE) and Enterprise Edition (EE), service-oriented architecture (SOA) and .NET. Oracle Entitlements Server 11gR1 offers fine-grained authorization in which a context for the authorization request is provided and access is granted or denied based on this. The core functionalities of Oracle Entitlements Server 11gR1 are based on the eXtensible Access Control Markup Language (XACML) specifications.
For this release, Authorization Policy Manager is the administration console for Oracle Entitlements Server. For purposes of the Oracle Entitlements Server documentation set, Authorization Policy Manager and variations of the Oracle Entitlements Server Administration Console (Administration Console, Console and the like) may be used interchangeably.
Oracle Entitlements Server is not meant to contain the functionality of the product released as Oracle Authorization Policy Manager product. When referred to in this documentation set, Authorization Policy Manager is simply the Administration Console.
Oracle Entitlements Server 11gR1 offers fine-grained authorization and centralized entitlements management across heterogeneous application environments. Additionally, Oracle Entitlements Server:
Distributes policies from the Administration Server to the decision endpoints.
Caches policies and authorization decisions for performance.
Updates security policies at run time.
Offers a flexible architecture that supports both embedded and remote decision points (for centralized or distributed policy decisions).
Separates security decision making from application logic.
Audits all access decisions and management operations.
Supports the eXtensible Access Control Markup Language (XACML) request/response protocol for authorization inquiries.
Integrates with existing security and identity systems by leveraging enterprise data in relational databases and LDAP directories.
From a high-level, Oracle Entitlements Server comprises centralized policy management with centralized or distributed policy decision making. The architecture of Oracle Entitlements Server is based on the interaction model of entities discussed in the XACML specifications. This model defines entities that provide a flexible architecture that can adapt to many components and deployments. Figure 1-1 illustrates the components of the Oracle Entitlements Server. Each of these components corresponds to one of the XACML entities.
Figure 1-1 Components of Oracle Entitlements Server
The following sections contain information on the Oracle Entitlements Server components and how they conform with the XACML entities.
The Policy Administration Point (PAP) is where policies used to protect a specified protected resource are created and managed. (In Figure 1-1, Administrative Server and Management API represent the PAP.) The PAP makes these rules available to the Policy Decision Point in order for that entity to reach a grant or deny decision for a request to access the protected resource. The Oracle Entitlements Server PAP is comprised of the Administration Console, management application programming interfaces (APIs) and management command line utilities. Figure 1-2 illustrates the architecture of these management and administration tools.
Figure 1-2 Oracle Entitlements Server PAP Architecture
When Oracle Entitlements Server is deployed, a Policy Decision Point (PDP) receives a request for authorization, evaluates it based on applicable policies, reaches a decision and returns the decision to the Policy Enforcement Point (PEP), the entity which first made the authorization call.
The PDP can also retrieve additional subject, resource, action and environment attributes from a Policy Information Point to add contextual information to the request. See Section 1.3.3, "The Policy Information Point" for more information.
The PEP then enforces the decision. The PEP is a software component that intercepts the request to the protected application, passes it to the PDP and enforces the security decision returned from the PDP. This software component can be the protected application itself or a Security Module. The PEP is always integrated within a Jave Standard Enterprise (JSE) application or a Java Enterprise Edition (JEE) web container.
The PDP may also return information with the decision - referred to as an obligation - that allows the decision to be enforced within a particular context. The application is not forced to act upon these obligations. See Oracle Fusion Middleware Developer's Guide for Oracle Entitlements Server for more information.
Oracle Entitlements Server offers two types of Security Modules. One type acts purely as a PDP by receiving requests and reaching decisions. The other type combines this PDP functionality with that of the PEP. The following sections illustrate how the Security Modules work.
When a Security Module acts purely as a PDP, its only functionality is decision making. It receives an authorization request and returns its decision to the PEP that originally made the authorization call. With the Security Module acting solely as the PDP, an external entity must act as the PEP - make the authorization call (using the Oracle Entitlements Server authorization API) and enforce the returned decision.
Figure 1-3 illustrates the process when the PEP entity making the call is the resource (application) itself. It receives the request for access, initiates authorization (through communication with the Security Module) and enforces the returned decision.
Figure 1-3 Application Acting as PEP Requests Decision from PDP
Figure 1-4 illustrates the process when the PEP entity is an agent or a plug-in (or similar software component) that intercepts the request before it reaches the application. The software component intercepts the request for access, initiates authorization (through communication with the Security Module) and forwards the decision returned from the Security Module to the application.
Figure 1-4 Agent Acting as PEP Intercepts Request and Makes Decision
Working together, these scenarios can offer a flexible authorization service. For example, the intermediary Web Services/XML gateway can request an authorization decision for a subject to access a portal. Assuming this primary decision is granted, the Web Services/XML gateway itself can then request secondary authorization decisions used to personalize the portal for the user that has been granted access.
When a Security Module acts in tandem as a PDP and a PEP, it intercepts authorization requests, makes a decision, and enforces the decision. With this release of Oracle Entitlements Server, there is one Security Module that works in this manner: the WebLogic Server Security Module.
The WebLogic Server Security Module plugs directly into an Oracle WebLogic Server container that executes the protected application and will automatically request an authorization. In this scenario, a subject-initiated request to the application is intercepted by the WebLogic Server for authorization. The WebLogic Server, after successful authentication, attempts to authorize the request by making a call to a set of authorization providers configured during the Security Module's installation.
For more information on Oracle WebLogic Server, see the Oracle WebLogic Server Documentation Library at
The Role Mapping and Authorization Proxy providers communicate with the Oracle Entitlements Server authorization engine (calling the PEP API which, in turn, calls the PDP). The PDP computes a decision and returns the decision to the PEP which returns an appropriate response to the WebLogic Server. (Optionally, the PDP may return an obligation with the decision.) If access is denied, the WebLogic Server throws a security exception and prevents access. If access is permitted, the WebLogic Server allows access. Figure 1-5 illustrates this scenario.
Figure 1-5 Security Module as PDP and PEP
The benefits of using the providers is to allow fine-grained component level authorization. For example, you can use the providers to protect access to a servlet URL while allowing the servlet itself to make additional PEP API calls to decide which elements should be rendered on the returned page. By default, the Role Mapping and Authorization Proxy providers are not enabled.
See Section 11.1, "Integrating with WebLogic Server" for the procedure to enable the authorization providers using the WebLogic Server console. Post-configuration parameters are documented in Section A.2.4, "WebLogic Server Security Module."
As mentioned in the previous paragraph's example, the application protected by the WebLogic Server can still make direct calls to Oracle Entitlements Server using the PEP API (as illustrated by Figure 1-3, "Application Acting as PEP Requests Decision from PDP") for purposes similar to those discussed in Section 18.104.22.168, "Security Module as PDP."
Figure 1-6 illustrates how the various types of Security Modules have been developed.
Figure 1-6 Security Module Architecture
Based on this topology, the services of a Security Module can be invoked in several ways.
The Java Security Module is a generic PDP that provides authorization decisions using Java API. This Security Module is supported on the following containers:
Java, Standard Edition (JSE)
The Multi-Protocol Security Module is an authorization service (based on service-oriented architecture principles) wrapped around a generic Java Security Module. It provides authorization decisions using RMI, Web Services and XACML (request and response). The Multi-Protocol Security Module is usually deployed on a central service rather then individual machines hosting the applications.
Figure 1-4, "Agent Acting as PEP Intercepts Request and Makes Decision" works similarly to the Multi-Protocol Security Module with an XML gateway; it intercepts requests and forces authorization before sending them to on to the destination.
The WebLogic Security Module is a custom made Java Security Module that includes both a PDP and a PEP. It can receive requests directly from the WebLogic Server without the need for explicit authorization API calls. It only runs on the WebLogic Server container.
Security Modules as central PDPs are supported for RMI, Web Services or XACML calls but Oracle Entitlements Server and the Security Modules cannot be in the same WebLogic Server domain.
See Oracle Fusion Middleware Developer's Guide for Oracle Entitlements Server for more information on requesting authorization decision and how Security Modules get updated policy information using the Policy Distribution Service.
As defined in the XACML specifications, the Policy Information Point (PIP) is a data repository - a source from which information can be retrieved for use when evaluating policies for an authorization decision. This allows policies to be data-driven in that the value of an attribute can impact the access decision. For example, if access to transfer money from a bank account is based on how much money is currently in the account, an attribute retriever can be used to get a value for the current balance.
In an Oracle Entitlements Server deployment, attribute retrievers serve the PIP thus, the terms PIP and attribute retriever may be used interchangeably. The Attribute Authorities component illustrated in Figure 1-1, "Components of Oracle Entitlements Server" would be considered the PIP. Out of the box, an attribute retriever is available for both, LDAP and relational database data sources. See Oracle Fusion Middleware Developer's Guide for Oracle Entitlements Server for more information on attribute retrievers.
The Oracle Entitlements Server authorization process involves the components described in Section 1.3, "Overview of the Oracle Entitlements Server Architecture". When a policy decision is requested, the PDP evaluates all policies related to the request and returns a grant or deny decision to the calling application. Figure 1-7 illustrates how the data flows during the policy authorization process.
Figure 1-7 How Data Flows in the Policy Authorization Process
Oracle Entitlements Server (acting as a PAP) is used to create and manage policies to protect a particular resource.
Policies in the policy repository are pushed to a policy cache, local to the PDP, by the Policy Distribution Service. The PDP reads policies from this cache. See Oracle Fusion Middleware Developer's Guide for Oracle Entitlements Server for more information.
A request for a resource is received by the PEP protecting it. The PEP can be the application itself or a Security Module - whichever makes the authorization call to Oracle Entitlements Server.
The PEP makes an authorization call to the PDP.
The Security Module PDP queries for additional subject, resource, action and environment attributes from the appropriate data source PIP.
The Security Module PDP evaluates the request and returns a response (and applicable obligations) to the PEP in the form of an authorization decision to grant or deny access.
The PEP fulfills any obligations, if applicable. An obligation is information returned with the decision upon which the PEP may or may not act. For example, an obligation may contain additional information concerning a decision to deny. The PEP entity is responsible for obligation fulfillment based on its settings. Oracle Entitlements Server is only responsible for forwarding the obligation based on policy configuration.
If access is permitted, the PEP grants the requester access to the resource; otherwise, access is denied.
Section 2.2, "How Oracle Entitlements Server Evaluates Policies" contains more details.
Oracle Entitlements Server supports a number of access control models. Many access control products support only one of these models but Oracle Entitlements Server has implemented a policy model with the flexibility to support many of them. You can deploy strictly based on one model or mix and match pieces of different models. The following sections contain information on the access control models.
The Role-Based Access Control (RBAC) authorization model uses roles to define the privileges of a user. First, roles are created. Following, permissions to perform certain operations are assigned to the roles and, finally, users or enterprise groups are assigned to the roles. Through role assignment, the assignee acquires the right to perform the assigned operations. Thus, RBAC makes management of individual permissions simply a matter of assigning the appropriate roles to the appropriate entity. Roles can also be combined in a hierarchy where higher-level roles subsume permissions owned by sub-roles. Application Roles are used when modeling Oracle Entitlements Server deployments based on RBAC.
Attribute-Based Access Control (ABAC) provides the capability to define fine grained authorization using attributes. Roles need not be created. An ABAC policy specifies one or more claims that need to be satisfied before a user is granted access; for example, the user must be a certain age. If the user can prove this claim, access is granted.
Constraints are used when modeling Oracle Entitlements Server deployments based on ABAC. For more information, see Oracle Fusion Middleware Developer's Guide for Oracle Entitlements Server.
Oracle Entitlements Server is built as an extension of Oracle Platform Security Services (OPSS). The OPSS security model is based on Java Authentication and Authorization Service (JAAS) security. JAAS institutes a permission based authorization system that implements Java-based security standards to support principal based and code based policies. A Java
Permission object represents permission to access a resource. For example, the following code creates a
FilePermission object representing read access to a file named
abc in the
perm = new java.io.FilePermission("/tmp/abc", "read");
Oracle Entitlements Server 11gR1 supports the Java Development Kit developer version 1.6 on either the Standard Edition or Enterprise Edition platforms
For more information, see the Java documentation at
The eXtensible Access Control Markup Language (XACML) is an access control model that describes how to interpret policies, and an access control policy language (written using XML). Oracle Entitlements Server implements the XACML 2.0 request and response standard as well as the architecture model (described in Section 1.3, "Overview of the Oracle Entitlements Server Architecture.") It also implements how XACML defines policies as a collection of principals, resources, actions and attributes. For more information, see the XACML specifications at
Oracle Entitlements Server has implemented the PEP Decision API, a part of the Open Az framework (
org.openliberty.openaz.azapi package provides access from a PEP to a remote or embedded PDP. The
org.openliberty.openaz.azapi.pep package (PEP API) has been implemented by Oracle Entitlements Server to be used by the PEP to issue authorization requests to a PDP. More information on the Open Az API can be found at
http://openaz.svn.sourceforge.net/viewvc/openaz/test/doc/index.html?org/openliberty/openaz/azapi/pep/package-summary.html. More information on the PEP API implementation can be found in Oracle Fusion Middleware Developer's Guide for Oracle Entitlements Server.
As implemented by Oracle Entitlements Server, the PEP API do not support authorization decisions for resources protected by Java permissions.