This chapter contains an overview of the features and architecture of Oracle Entitlements Server. It contains the following sections:
Access control refers to 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 or principal (most often a real person). An authorization 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 operations are dependent on the type of resource. For example, the 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-specific 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 Mapping Policies and Authorization Policies. A Role Mapping Policy defines constraints regarding which users are assigned roles and can map Application Roles in the Policy Store to external groups in the Identity Store. This mapping allows users in external groups to access resources as specified by the Application Roles. The mapping is allowed to be many-to-many. An Authorization Policy defines access to the protected 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 of Oracle Entitlements Server.
Oracle Entitlements Server 11g represents a consolidation of Oracle Platform Security Services with Oracle Entitlements Server 10g (formerly BEA AquaLogic Enterprise Security). While Oracle Platform Security Services (OPSS) is a Java Authentication and Authorization Services (JAAS) security provider that offers coarse-grained authorization, Oracle Entitlements Server 11g 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 11g offers fine-grained authorization in which a context for the authorization request may be provided and access is granted or denied based on this. The Oracle Entitlements Server 11g architecture is based on the interaction model described in the core eXtensible Access Control Markup Language (XACML) specifications. See Section 1.3, "Overview of the Oracle Entitlements Server Architecture" for details.
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. See Chapter 3, "Getting Started" for more information on the Administration Console.
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 11gR2 offers fine-grained authorization and centralized entitlements management across heterogeneous application environments. Additionally, this release of Oracle Entitlements Server 11gR2 offers:
Support for all data types and functions as defined in the XACML 3.0 specifications
Support for viewing and modification of Oracle Platform Security Services created Application Grants (application policies)
Logging enhancements to simplify policy evaluation analysis
Support for permission based advanced policies
Enhanced PEP API query requests
Administration Console support for plugging in multiple identity stores
SMConfig UI, the Security Module configuration interface
Support for .NET resources
Security Modules for Java containers, Web Services (on WebLogic Server), Oracle Service Bus, Microsoft Sharepoint, JBoss, and Tomcat
From a high-level, Oracle Entitlements Server (OES) 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.
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. 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 authorization management application programming interfaces (API). (In Figure 1-1, Administrative Server and Management API represent the PAP.) Access to (and use of) the PAP can be achieved with the Administration Console, the WebLogic Scripting Tool (WLST), the Policy Distribution Component or various other tools (including
migrateSecurityStore and those for reassociation). Figure 1-2 illustrates the 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 PEP then enforces the decision.
The PDP can retrieve additional subject, resource, action and environment attributes from a Policy Information Point to add context to the request. See Section 1.3.3, "The Policy Information Point" for more information.
The PEP doesn't intercept authorization requests; it intercepts a request for access sent to an application and authorizes the request by forming an authorization request and sending it to the PDP. Upon receipt, it enforces the grant or deny decision returned by the PDP. The PEP is a software component that can be the protected application itself or a Security Module.
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 Chapter 2, "Understanding the Policy Model" for more information.
Oracle Entitlements Server offers two types of Security Modules. One type was developed to act purely as a PDP by receiving requests and reaching decisions. The other type combines this PDP functionality with that of the PEP; thus, this Security Module type receives requests, reaches authorization decisions and enforces the decision. Chapter 7, "Deploying the Policy Decision Point" contains information on how the Security Module may be deployed. The following sections illustrate how the Security Modules work.
A Security Module is referred to as the OES Client before and during its installation process.
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-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.
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, the WebLogic Server, Oracle Service Bus and Microsoft SharePoint Security Modules work in this manner.
For more information on Oracle WebLogic Server, see the Oracle WebLogic Server Documentation Library at
For example, 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.
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.
The benefit of using the providers is 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 (as illustrated by Figure 1-3, "Application Acting as PEP Requests Decision from PDP"). By default, the Role Mapping and Authorization Proxy providers are not enabled.
Figure 1-6 illustrates how the various types of Security Modules have been developed.
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 or .NET API. This Security Module is supported on the following containers:
Java, Standard Edition (JSE)
Microsoft Sharepoint Server
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 can be co-located with the protected application or deployed on a central server.
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, Oracle Service Bus (OSB) and Sharepoint Security Modules are Security Modules that include both a PDP and a PEP. They can receive requests directly from the container without the need for explicit authorization API calls.
Security Modules deployed centrally 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. For more information on the deployment models, see Chapter 7, "Deploying the Policy Decision Point."
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. See Chapter 8, "Managing Security Module Configurations" and Chapter 9, "Securing Environment Specific Resources" for details on configuring and using Security Modules.
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 in this documentation. 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 and Appendix B, "Configuring Attribute Retrievers Manually" 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.
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 external 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. This model is useful for more coarse-grain authorization; for example, when your authorization requirements are not complex. Application Roles are used for 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. Conditions are used when modeling Oracle Entitlements Server deployments based on ABAC. For more information, see Section 4.6, "Using the Condition Builder."
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 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 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
Only support for XACML 3.0 data types and functions has been added to this release of Oracle Entitlements Server.
Oracle Entitlements Server has implemented the PEP 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.