Skip Headers
Oracle® Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition)
11g Release 1 (11.1.4)

Part Number E20839-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

2 Understanding The Policy Model

A policy is a set of criteria that, when evaluated by Oracle Entitlements Server, specifies whether a user will be granted access to a particular protected resource or assignment to a particular role. This chapter contains an overview of the Oracle Entitlements Server policy model, the elements that comprise a policy and how the elements are organized in the policy store. It contains the following sections:

2.1 Understanding Oracle Entitlements Server Policies

Oracle Entitlements Server supports the creation of Authorization Policies and Role Mapping Policies. Section 2.1.1, "Granting and Denying Access Using Policies" explains how these two types of policies work together to grant or deny access to a protected resource. The referenced sections below contain detailed information regarding these policy types including how they are used.

2.1.1 Granting and Denying Access Using Policies

By default, all access to a protected resource is denied until an Authorization Policy that explicitly grants access to it is written and distributed. If the Authorization Policy only grants access to a role, the requesting user must be statically assigned to it or a Role Mapping Policy that assigns the requestor (or not) to the defined role must be written and distributed. If an Authorization Policy denies a previously granted entitlement, it takes precedence over the previous grant. Explicit DENY Authorization Policies cannot be overruled. A practical use of a DENY policy is to explicitly deny an entitlement to ensure that a user or group can never gain access to a specific resource.

2.1.2 Understanding the Authorization Policy

An Authorization Policy is created to grant or deny access to a particular resource based on the profile of the requesting user. From a high level, the Authorization Policy defines an association between an effect (GRANT or DENY), a principal (requesting user), the target resource, the resource's allowed actions and an optional condition. An Authorization Policy is applicable to a request for access if the parameters in the request match those specified in the policy. Consider this Authorization Policy definition:

GRANT the SupportManagerEast role MODIFY access to the Incidents servlet 
  if the request is made from an IP address of 229.188.21.21

This Authorization Policy will GRANT any user that is a member of the SupportManagerEast role access to the Incidents servlet for the purpose of modifying it. The policy is also constrained by a condition - the request must be made from IP address 229.188.21.21. Thus, if the parameters in the request match the parameters in the policy (a member of the SupportManagerEast role wants to modify the Incidents servlet), and the request is made from IP address 229.188.21.21, the request is granted. If the parameters in the request match the parameters in the policy (a member of the SupportManagerEast role wants to modify the Incidents servlet) but the request is NOT made from IP address 229.188.21.21, the policy is ignored. The following list of terms and values are extracted from this policy definition and comprise the components of the Authorization Policy.

  • Effect: GRANT

  • Action: MODIFY

  • Resource: Incidents servlet

  • Principal: member of SupportManagerEast role

  • Condition/Constraint: IP address 229.188.21.21

Figure 2-1 illustrates how the components of this policy map to the Oracle Entitlements Server Authorization Policy objects.

Figure 2-1 Policy Components Mapped to Authorization Policy Objects

Surrounding text describes Figure 2-1 .

For information on how to create, update and delete Authorization Policies, see Section 3.5.5, "Managing Authorization Policies."

2.1.3 Understanding Role Assignments and the Role Mapping Policy

An Application Role is a collection of users, groups, or other Application Roles defined using Oracle Entitlements Server. It can be mapped to an enterprise user, group, or external role in an identity store, or another Application Role in the Oracle Entitlements Server policy store. (Assigning one Application Role to another Application Role allows you to build an Application Role hierarchy.) Application Roles can be assigned to a user in either of the following ways:

  • By statically granting a specific user membership in the role.

  • By referencing the Application Role in a Role Mapping Policy that will be used to dynamically assign role membership at runtime.

A Role Mapping Policy allows you to dynamically assign (GRANT) role membership to a user or dynamically revoke (DENY) role membership from a user. Consider the following Role Mapping Policy definition:

GRANT the Employee group application role SupportManageEast 
   if the request is made from an IP address of 229.188.21.21

This policy grants the SupportManagerEast Application Role to any user that is a member of the group Employee. The policy is constrained by a condition though - the request must be made from IP address 229.188.21.21. Thus, if the parameters in the request match the parameters in the Role Mapping Policy (the requesting user is a member of the Employee group), and the request is made from IP address 229.188.21.21, the Application Role is granted. If the request is not made from the defined IP address, the Role Mapping Policy is ignored. The following terms and values are applicable to this Role Mapping Policy definition.

  • Effect: GRANT

  • Application Role: SupportManagerEast

  • Principal: member of Employee group

  • Condition/Constraint: IP address 229.188.21.21

Figure 2-2 illustrates how the components of this policy map to the Oracle Entitlements Server Role Mapping Policy objects.

Figure 2-2 Policy Components Mapped to Role Mapping Policy Objects

Surrounding text describes Figure 2-2 .

A Role Mapping Policy can also be used to prevent specific users from being assigned an Application Role. Consider the following Role Mapping Policy definition:

DENY the Customers group application role GoldCircle 
   if the account balance is less then $10,000

This policy denies the GoldCircle Application Role to any members of the group Customers IF their account balance is less then $10,000. For information on how to create, update and delete Role Mapping Policies, see Section 3.5.7, "Managing Role Mapping Policies."

2.2 How Oracle Entitlements Server Evaluates Policies

During Oracle Entitlements Server runtime evaluation, the following occurs:

  1. Based on the subject, a list of Application Roles is determined by:

    1. Retrieving the user's static role membership.

    2. Evaluating all applicable Role Mapping Policies with a GRANT effect and adding them to the list of roles previously determined.

    3. Evaluating all applicable Role Mapping Policies with a DENY effect and removing them from the list of roles previously determined.

  2. Based on the subject and list of retrieved Application Roles, a list of Authorization Policies is evaluated to find any that might be applicable based on the grantee, target matching and conditions. (The actions allowed on the resource are defined by the Authorization Policy.)

  3. A final authorization decision is based on the “DENY overrides” combining algorithm and returned to the calling application.

2.3 The Policy Object Glossary

The policy objects defined in this section can be created, provisioned or managed using the Authorization Policy Manager Administration Console.

2.4 Implementing a Policy Use Case

Oracle Entitlements Server provides the ability to externalize policy management and policy decision making logic from an organization's resources. It secures access to the organization's resources by implementing policies that specify the users, groups, and roles that can access them. Resources can be application software components (URLs, Enterprise JavaBeans, JavaServer Pages) or enterprise business objects (customer accounts, patient records). This use case considers how the policy model can be used to secure the financial services offered by Acme Investment Bank. It is based on the concept of hierarchical resources - resources are organized as a tree and inherit from their parent elements.

Note:

Oracle Entitlements Server also supports the concept of non-hierarchical (flat) resources. See Section 3.5.2, "Managing Resource Types" for more information.

In this use case, the following conditions apply:

Figure 2-3 illustrates the financial services scenario by organizing the protected resources into business objects and software components. Paul is a bank employee who is an account manager and can set transfer limits up to $100,000 on the accounts that he manages. Paul manages account owner Bob's family account which has a transfer limit of $10,000. Bob manages his family account and a child account he created for Mary who may not transfer money. These accounts are considered business objects and are protected as such.

Account owner Bob has access to a Summary report generated for his family account. Account manager Paul has access to Bob's Summary report and his own Account Manager report. Child account holder Mary has access to no reports. These reports, generated as JavaServer Pages, are considered software components and are protected as such.

Figure 2-3 Use Case for Software Components and Business Objects

Surrounding text describes Figure 2-3 .

For any given user, a request for access to a financial services account (business object) or account report (software component) generates a decision based on the following questions:

  1. Is this user an account holder, account owner or an account manager?

  2. Can this user transfer funds from this account (subject to the role, transfer limit, and time of transaction)?

  3. What reports can this user access?

The first two questions can be decided using policies created to protect business objects, while the last can be decided using policies created to protect software components. The following sections illustrate how to conceptualize the policies.

2.4.1 Protecting Software Components

The Account Reports node in Figure 2-3, "Use Case for Software Components and Business Objects" represents the reporting application. Summary.jsp and Detailed.jsp are the software components. There are several options from which to choose when deciding how to model policies for securing these software components. One option is to set an Authorization Policy for the top node reporting application by using group membership. The following example illustrates how access is explicitly granted by naming the resource and the group of users that can access it.

GRANT the BankManagers group access to the AccountReports node 

This top down Authorization Policy grants access to the Account Reports node for anyone in the BankManagers group. Because these resources are hierarchical, anyone in the allowed group has access to both the Summary and Detailed reports. But this access may be restricted using system-based or attribute-based conditions. For example, adding a condition based on time or based on the value of a specific user, group, or resource attribute would further limit access. The following example illustrates how a time-based condition restricts access of the reports to typical office hours.

GRANT the BankManagers group access to the AccountReports node 
  IF the request is made between 09:00 and 17:00

Another option can set the top down Authorization Policy by defining the principal as a role rather than a group. A role is comprised of users or groups. (An LDAP role would be granted enterprise wide whereas an Application Role is specific to the Application for which it was configured.)

Note:

A user can be assigned to a role through direct membership or a Role Mapping Policy.

In the following example, the resource is explicitly named and access is implicitly granted to a user if the user is assigned the defined role.

GRANT access to AccountReports node if user has BankManagers role

You can also dynamically assign the BankManagers role to users accessing the reporting application if they are a member of the BankManagers group (as illustrated below).

GRANT BankManagers role to members of BankManagers group
  FOR access to AccountReports node

Another way to define the previous Authorization Policy is to assign the role based on a user attribute value rather than group membership. (In a large enterprise, it is typically more efficient to assign users based on attributes than on group membership.) The following example assigns the BankManagers role to the requesting user if the value of the UserType attribute in the user's profile is BankManager.

GRANT BankManagers role to anyone defined by UserType 'BankManager'
  FOR access to the AccountReports node

The previous examples represent Authorization Policies that scope from the top node reporting application down to the reports but Authorization Policies can also be defined for the specific report nodes. The following example grants access to the Summary.jsp report to all assignees of the BankManagers and AccountOwners roles. The additional condition is that the principal requesting access must be listed on the account to which the report pertains.

GRANT Summary.jsp access to all members of BankManagers and AccountOwners role
  IF the requesting assignee is listed as OWNER or MANAGER on specified account

Another example illustrates how access to the Detailed.jsp report can be granted to anyone who is assigned the BankManager role.

GRANT Detailed.jsp access to all assignees of BankManagers role

The previous examples show how an Authorization Policy can be modeled for specific application software components. In a real enterprise scenario, each application may have tens or hundreds of resources so it might not be practical to write an Authorization Policy for each one. The concept of resource attributes has been implemented by Oracle Entitlements Server to address this proliferation of application software component resources and associated Authorization Policies.

By associating a resource with an attribute, you can grant access based on the value of the attribute. For example, filetype could be a resource attribute that is used to define an HTML page, an image, or a PDF. By defining a condition as if filetype=pdf, you can grant access to all PDF files that are associated with the resource. The following example uses a resource attribute; it allows users assigned the BankManagers and AccountOwners role access to all reports although access is granted only if the report type being requested matches the value of the UserReportType attribute in the specific user's profile.

GRANT users assigned BankManagers or AccountOwners roles 
     access to AccountReports
   IF requested ReportType matches UserReportType attribute value 
     in user profile

This policy grants BankManagers and AccountOwners access to all reports although access is constrained based on matching resource attribute values with user attribute values. An advantage of this approach is that the policy governing access need not change as resources are added to, or removed from, an application. As resources change, the ReportType resource attribute attached to the application continues to govern access.

2.4.2 Protecting Business Objects

There are several options from which to choose when deciding how to model Authorization Policies for securing business objects. In this banking scenario, business objects are bank accounts. Figure 2-3, "Use Case for Software Components and Business Objects" illustrates the Acme bank account structure.

Each bank account can have a manager, an owner, and a holder with each scope assigned a certain set of privileges (or entitlements). The policy evaluating what a user can do on the bank account is then based on the user's attributes rather than the resource. The following example allows anyone to transfer money but that privilege is only granted if the user is defined as owner of the account requested and the amount of money being transferred is less than or equal to the limit defined for the user.

GRANT anyone transfer privileges only
   IF the user is listed as OWNER on specified account
  AND transfer amount is equal to or less than the transfer limit

There is another option to acquire a user's entitlements. Rather than comparing a transfer request to a transfer limit, Oracle Entitlements Server can return the transfer limit amount as the output of evaluation. In this scenario, the user's ability to access the account is verified but the transfer amount is returned to the caller (in a Java object) as an obligation. This leaves verification that the transfer amount is within the transfer limit up to the application. The following example illustrates this model.

GRANT anyone transfer privileges only
   IF the user is listed as OWNER on specified account
  THEN RETURN transfer limit to calling application

A model where the bank account corresponds to an individual resource instance can also be used; however, this would yield a proliferation of policies (one for each account) and become unmanageable. For example, if Acme Investment Bank had 100,000 accounts, it would need at least 100,000 policies just to manage transfers. For more information on adding obligations, see Section 3.5.5, "Managing Authorization Policies."