|
|
This section covers the following topics:
Oracle Entitlements Server is a fine-grained entitlements engine that allows the user to centrally define and manage a set of policies to control access to both software components (for example, URLs, EJBs, and EJB methods) and business objects (for example, accounts and patient records) that make up the application. The policies are evaluated and enforced locally in the application container so application context can be included as part of the access control decision. A major benefit of Oracle Entitlements Server is that it allows you to remove security logic from the application. This enables you to take access control decisions out of the hands of developers and define and manage access control consistently across multiple applications.
Policies are statements that work together to define access control for business resources. A resource is any object that represents an underlying application or application component that needs to be protected from unauthorized access. A well-written set of policies accurately represents the access control requirements for your business, is easy to manage, and is designed for maximum efficiency.
Before you begin to write policies, you must know the access control requirements of the business, the resources that are to be protected, the users attempting access, and the actions that users must perform on the resources.
There are two types of policies: authorization and role mapping:
All actions on protected resources are implicitly denied until authorization policies grant specific actions. In other words, an authorization policy must grant actions on resources before users can do anything. Once access is granted, it must be explicitly denied to revoke that right — and explicit DENY policies cannot be overruled.
This provides security that errs on the side of caution. For example, if you forget to deploy an authorization policy, someone will be denied access. While this is problematic, from a security standpoint it is preferable to inadvertently allowing access to resources that should be protected. Users who are denied required access will almost certainly ask for corrective action, while users inadvertently granted unauthorized access are unlikely to bring this to the attention of administrators — with potentially disastrous consequences.
All policies follow a specified sentence-like syntax. The Entitlements Administration Application provides a graphical interface that facilitates construction of policies. The constraints portion of the policies can be directly entered as described in this guide, however the main part of the policy is constructed via the graphical interface.
A single policy can have multiple actions, resources, and defined subjects. The policy syntax is as follows:
Effect (action|role, resource, subject, delegator) IF constraint;
A resource represents an underlying application or application component (or any object), that can be protected by authorization policies. Resources can be specific application software components managed by the container (for example, URLs, EJBs, JSPs, and so on) or any business object in the application (for example, Reports, Transactions, Revenue Charts). Resources may have attributes; for example bank accounts have owners and transfer limits. In the OES, resources can be defined in hierarchies such that child resources can be secured by policies set on the parent.
When defining resources you start by defining the top-level resource in the resource tree and then define the resources that make up the tree. Once a resource is defined, you can write authorization policies to grant or deny access actions to users, groups, or roles for the top-level resource and resources on the tree. Hence, defining a resource tree is a necessary prerequisite to writing policies.
Some typical resources that you might want to protect include:
| Note: | In development mode, you may use the Resource Discovery to help define resources in a particular application. For more information, see “Resource Discovery” on page 4-79. |
If your policy model permits it, you may dispense with defining a entire resource hierarchy. By creating only the top-level or ‘root’ resource and setting it as a ‘virtual resource’, all policies assigned to the root resource will also its child resources in the application — even though the child resources are not explicitly defined in OES.
For large applications with many hierarchical resources (e.g. web URLs) this can mean a considerably smaller resource tree.
You can associate attributes with resources. An attribute contains information about a characteristic of the resource to which it is associated. For example, filetype could be a resource attribute that you use to define an html, image, jsp, or pdf file type. Then, you could grant access to all pdf files in a directory by adding the condition: if filetype = pdf.
An action represents an activity or task that can be executed on a resource. Actions in a policy specify what action is to be granted or denied on a resource. Actions can be standard actions (for example Get and Post on a URL) or a custom action on a business object (for example, transfer for a bank account). Actions that may be granted or denied on a particular resource are limited by the operations supported by the resource. For example, a simple text file may support Read, Write, Copy, Edit, and Delete operations. Similarly an executable (.exe) may support operations such as Copy, Delete, and Execute. A more complex resource may support far more complex actions. For example, a checking account application may support operations such as deposit, withdrawal, view account balance, view account history, transfer to savings, and transfer from savings.
In addition to the actions provided in the product, you can define your own actions. For example, if you have the business security requirement: "Only lead tellers can open an account," you might define an OpenAccount action and a LeadTellers role. Now, to grant LeadTellers (the role) the authority to open an account (the action), the authorization policy might look like this:
grant(//priv/OpenAccount, //app/policy/TellerApp, //role/LeadTellers)
if time24 in [900..1700] AND
dayofweek in [monday..friday];
When this policy is deployed, only tellers who are assigned the LeadTellers role are allowed to used the TellerApp to open an account and they may do so only between the hours of 9:00 AM and 5:00 PM (a time-of-day constraint) on Monday through Friday (a days-of-the-week constraint).
An action group is an organizational object that allows you to group similar actions for ease of management. They are not used in policy definitions. Like actions, you may create action groups if those provided out-of-box are not sufficient.
An identity directory serves as a logical container for a collection of users and groups, and possibly identity attributes. In this release, identity directories are managed at the organization level. Once you populate an identity directory with users and groups, they may be included in the authorization policies and role mapping policies in an application under the organization. I.
You may define multiple identity directories depending on the level of granularity needed to separate your user community. When one directory is used, all users and groups must have a unique name. If this presents a problem when integrating multiple identity repositories, use separate directories. For example, you might have one directory for customers, one for employees, and one for partners.
A user or group can contain attributes that further describe who they are and what they can do. You can use these identity attributes to define dynamic constraints that are evaluated when a policy decision is made. For example, consider that account balance is an attribute of a user. To allow customers with an account balance over $100,000 to access the premier banking features of your application, you define accountbalance as an attribute and apply it to each customer in the bankusers group. Next, you define the premierbanking role and write a role mapping policy that only allows access to the application if the customer is in the premierbanking role. Then you write an authorization policy that defines the actions you want to allow on the bankapp resource and define the subject as the role premierbanking.
Grant(//role/premierbanking,//app/policy/bankapp, //sgrp/bankusers/customers/) if accountbalance > 100000
This role mapping policy allows customers who are assigned the premierbanking role to access the resource called bankapp if they have an accountbalance of over $100,000.
In order to use Identity Attributes in authorization or role mapping policies you must configure ALESIdentityAttributeRetriever for ASI Authorization Provider.
A group is a collection of users that have something in common, such as a department, a job function, or a job title. For example, a group named Accounting might contain users in the accounting department. It is important to realize that this does not directly reflect what access rights they have. A group can contain either users or other groups; users who are assigned to a group are called group members. Nested memberships of groups within a group form a hierarchy. Group membership can be assigned only from within the same directory. Groups have a static identity, or name, which you assign.
If a group has subgroups and an authorization policy grants certain actions to the group, the members of subgroups will have the same actions. This is true because each member of a subgroup is by default a member of the parent group.
In addition to managing groups in the policy database, Oracle Entitlements Server can use group membership information from a corporate directory. Typically, a group hierarchy is based on an organizational model of the company, although this is not a requirement. For example, the source of your user data might be an employee database, where users belong to four groups: the employee group, the Sales department group, the London office group, and the star-salesmen group.
Thus, you want to create groups of users whose tasks are related and for whom the policy enforcement is the same. In the following example (see Figure 2-1), Tellers are assigned to the Teller Group.
A user corresponds to an individual who makes a request to access a resource, although a user can also be an automated process that accesses a resource. You can assign users to groups from the same directory. Each user within a directory must have a unique identity or user name. Users can be associated with certain characteristics or attributes that contain information about the user. Policies can be written specifically for individual users, but keep in mind that it may be more efficient to write policies that apply to a collection of users defined as a role or a group. Oracle Entitlements Server supports both techniques.
To specify the access control requirements for resources you write a set of policies that may include role mapping policies and authorization policies.
The following topics describe the different types of policies:
Roles provide a useful abstraction of Users or Groups. For example, the Accounting Manager role may be assigned to a specific Group of individuals, but only in the context of the Payroll application. In another context, the same User or Group does not have that role. Roles are defined by Role Mapping Policies. Roles can be created in a hierarchy such that Users who are granted actions based on a child role inherit the actions from that role's parents. Users denied actions based on a parent role are also denied actions for that role's children.
| Note: | This discussion of roles does not apply to the new Organization Administrator and Application Administrator roles provided in the Entitlements Administration Application. |
Separation of Duties enables an administer to exclude users from a specified role if they are members of another specified role. For example, an administrator may prevent users mapped to the Traders role from also being mapped to the Trade Approvers role.
Roles can have attributes. Role attribute inheritance follows the same logic as Role inheritance.
The basic format of a role mapping policy is as follows:
grant|deny(role, resource, subjects[users, groups]) IF constraints;
Where the grant|deny portion is the policy effect and either allows or prohibits the role to the subject for the given resource, the role defines the role, the resource is the application or application component to which the role is scoped, subjects specify which users and groups belong to the role, and constraints define any conditions that apply to the role.
For example, the following policy grants the accountants role to the user Bill on the payroll resource:
GRANT(//role/accountants, //app/policy/acme/payroll, //user/acme/Bill/);
At runtime, user access actions are computed based on the roles the user has been assigned — either explicitly or through a role mapping policy — at the time an access request is made. Unlike groups which persist for the duration of a runtime session, roles are dynamically assigned to users by processing role mapping policies. This significantly reduces the number of policies required and makes features like role delegation easier to manage.
A role may apply to one or more users and groups and usually refers to some set of related tasks. For example, a group of bank tellers might have access to the same set of applications (resources) to perform specific banking tasks; thus, you might have a role called TellerRole and assign the BankTellers group to that role. Figure 2-2, Role Mapping Policy shows a group of tellers who belong to a Teller group that has membership in the CustomerService role that, in turn, has access to the Teller resource. The actions allowed on that resource are defined by an authorization policy, which you also define. Now, anyone who is not in the CustomerService Role does not have access to the Teller resource. You can also apply restrictions and conditions to limit access to the resource at runtime by defining the constraints such as time-of-day or day-of-the-week on the role mapping policy and/or the authorization policy.
An authorization policy specifies what a user is allowed to do with a resource. The syntax of an authorization policy is as follows:
grant|deny(action, resource, subjects[users, groups, roles]) IF constraints;
Where the grant|deny portion is the policy effect and either allows or prohibits the action to the subject for the given resource, the action defines the action, resource defines the application or application component of the action, subjects specify which users, groups, and roles are granted the action, and constraints defines any conditions that apply to the action.
For example, this policy grants any actions supported by the acme payroll application (the resource) to the user agarcia in the acme directory:
GRANT(//priv/any, //app/policy/acme/payroll, //user/acme/agarcia/);
The policy grants any actions supported by the acme payroll application (the resource) to the role accountants so only users and groups who have been granted the accountants role are granted this action:
GRANT(//priv/any, //app/policy/acme/payroll, //role/accountants/);
Therefore, before anyone can gain this action, a role mapping policy has to be written and deployed that grants this role to a user or a group.
It is important to note that by default, all access to a resource is denied until an authorization policy is written and deployed that explicitly grants an access action, or an entitlement, on that resource to a user, group, or role. If the authorization policy grants access to a role, a corresponding role mapping policy must assign a user or a group that role.
An authorization policy that denies a previously-granted entitlement takes precedence over the 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. For example, this policy denies the view action related to the acme payroll application to everyone belonging to the group named receptionist in the acme directory:
DENY (//priv/view, //app/policy/acme/payroll, //sgrp/acme/receptionist/);
Delegation allows you to share the actions of one user with other users.
DELEGATE (action|role, resource, subject, delegator) IF constraint;
A DELEGATE policy that delegates a action allows you to share the actions of one user with other users and/or groups. You may also add a constraint that restricts this sharing to a certain time of day or day of the week, for example:
DELEGATE (//priv/any, //app/policy/acme, //user/acme/joe/, //user/acme/larry/) if dayofweek in [monday..friday];
At runtime, this policy delegates any actions that larry (the delegator) has on the acme application to joe if the day of the week is Monday, Tuesday, Wednesday, Thursday, or Friday.
A DELEGATE policy that delegates a role allows you to share a role of one user with another user or group. You may also add a constraint that restricts this sharing to a certain time of day or date range, for example:
DELEGATE (//role/accountants, //app/policy/acme, //user/acme/joe/, //user/acme/bill/) IF ThisMonth = december;
delegates the role accountants on the acme application from bill (the delegator) to joe at runtime if the current mouth is December.
| Note: | Before a delegator’s action or role can be delegated, the ARME must verify that the delegator has the action or role to be delegated on the specified resource. To perform the verification, the ARME uses information about the delegator (password, groups, roles) that is stored in the policy database to build a Subject for the delegator. If the database does not contain the required information, the delegation policy will not be executed. |
Table 2-1 summarizes the functions of authorization and role mapping policies and highlights the differences.
An extension is a variable that represents either a predefined value (for example, days of the week) or a value that is dynamically defined at runtime (the date). You use extensions in policies as attributes. To help you design policies, built-in extensions are pre-defined for your use. You can also define custom extensions to suit your requirements.
You can define three types of extensions:
A constant is a named value or set of values that does not change at runtime. You can reference constants in policies. For example, if you set a constant named Rate to 12, policies can then refer to the constant Rate rather than using its literal value, 12. Using constants in policies makes them more readable and makes changes to values that are used across of set policies easier
Constants are especially useful if the value changes periodically and you use the constant in more than one location. For example, if you enter a rate value 12 into multiple policies, you need to individually change each one. Instead, if you use the constant Rate, you can edit the value once and have it take effect in every policy that refers to the constant.
Attributes represent characteristics that define dynamic values, users, groups, and configurations. Attributes may be associated with users or groups (identity attributes), resources (resource attributes), or policy requests (dynamic attributes). Attributes may be descriptive, may be used to configure policy engine behavior, manage delegated administration, or used in forming policy as part of the policy constraint.
Attributes must have a defined type that denotes the range of legal values it may have. A number of predefined types exist, such as string, integer, date, time, and IP address. You can also use custom types. The value of the attribute may be assigned to only one instance of an attribute. An attribute may be a multi-valued list.
An evaluation function is a named function that can be used in a policy constraint to perform more advanced operations. Each function may have a number of parameters and returns a Boolean result of true or false.
Oracle Entitlements Server provides a number of predefined evaluation functions and also allows you to declare your own custom evaluation functions. You can use a predefined function in your application by using a plug-in extension that a programmer creates specifically for your application. To use an evaluation function, you must register it as a plug-in with the authorization and role mapping providers used in the Security Service Module (SSM) configuration and declare it in a policy. For information about creating and using plug-in extensions, see Provider Extensions in the Administration Reference.
|