|
|
The following topics are covered in this section:
To write and deploy a set of policies, perform the following tasks (see Figure 3-1):
Task 1: Define the security requirements for your business. Understand the functions of your applications and the various types of users who need to access them under different circumstances.
Task 2: Using the Entitlements Administration Application, define an organization to represent your enterprise, company, or other organizational unit. Under the organization, define an identity directory and populate the directory with users, groups, and identity attributes. Also define organization administrators.
Task 3: Under the organization, define the application to represent the application to be secured and bind it to an SSM. Also define application administrators.
Task 4: Under the application, define the resources you want to protect, the actions that may be performed on these resources, extensions to use in policies, the business roles involved, and the policy definitions that will enforced when the application is accessed by users.
Task 5: Write role policies that control the assignment of users and groups to business roles.
Task 6: Write authorization policies that control what actions can be performed by what users on the application resources.
Task 8: Deploy the policies to the SSM. The SSM starts to enforce policies only after the policies are deployed.
Subsequent sections of this document describe how to use the Entitlements Administrative Application to perform the tasks described above.
| Notes: |
The Oracle Entitlements Server provides the following services and components for securing access to resources:
This service authenticates a user in one of two ways:
You can configure multiple authentication services to authenticate, assert identity, and collect additional group or attribute information at authentication time.
Once the user is authenticated, the service will create a subject object. The subject can contain one or more user principles with attribute information, one or more group principles for the groups in which the user has membership, and any attributes associated with those groups. The subject is provided to the authorization and role mapping services.
Given the subject, which is provided by the authentication service, the role mapping service evaluates the existing role policies to determine if a user or group is granted a role on the requested resource. Role membership rules can be time-based so that users can delegate their actions for a limited time (for example, when they go on vacation). Roles are always associated with resources and can be granted broadly or within the context of a particular application resource.
The actual authorization decision (isAccessAllowed) is made based on identity, group, or role membership.
The authorization service evaluates access control policies to determine what a user can do on a particular resource. It will evaluate any constraints against static data (such as user attributes retrieved) or dynamic data retrieved at runtime when the policy is evaluated. Further, the authorization service can take application context (for example, EJB parameter values) into account at evaluation time. The authorization service can return authorization decisions or entitlements through the report function.
The authorization service supports the use of multiple authorization providers. When multiple authorization providers are used, a custom adjudicator is required to determine the outcome when conflicts occur between these providers.
The credential mapping service provides a mechanism to address single sign-on to enterprise systems. This service can map user identity to an appropriate set of credentials for authentication to enterprise applications, such as PeopleSoft, SAP, and relational databases. This service can also be used to remove the need to embed credentials within application code. A number of identity token formats can be used to represent the user’s identity, including SAML.
At runtime, the ASI Authorizer, located in the SSM instance where the polices are deployed, uses role mapping policies and authorization policies to make decisions that grant or deny access.
| Note: | The ASI Authorizer is also known as the Authorization and Role Mapping Engine (ARME). |
Figure 3-2 shows the access control decision process. As illustrated, before you can write policies to define access control for your business resources, you must define those resources, the associated user identity, and any custom extensions you may want to use. Once resources and user identify are defined and the policies are written, they do not take effect until they are bound to the Authorization and Role Mapping providers in the deployed SSM. At runtime, user requests to perform actions on specific resources are evaluated to determine whether the user is granted the requested access.
The following sections describe how to write security policies using the Entitlements Administrative Application:
The Entitlements Administrative Application provides the ability to define and distribute policies that secure applications.
| Notes: |
An organization represents a company, department, or any business unit required. It serves as a container for one or more applications. The following type of information can be managed at the organization level:
Identities — There are three types of identities: Identity Directories, Users, and Groups. An identity directory is an organizational object used to contain groups and users. You may use one identity directory for all users/groups or multiple directories to partition users/groups as needed.
Organization Administrators — Allows you to set up Organization Administrators with specific administrative rights to manage an organization's identities, applications and application components, and policies.
| Note: | Previous releases of this product did not provide an organization object - the policy components for all secured applications were maintained in one flat structure. To provide support for backward compatibility, a reserved organization (RootOrg/DefaultOrg) has been provided to contain all policy components that were defined in previous versions. These components can continued to be managed as in previous releases. |
Each defined identity directory is accessed under an organization’s Identities tab. The users and groups defined in an identity directory can be used in the policy definitions in all applications in the organization.
For instructions, consult the Entitlements Administration Application help system.
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 identity directory. Groups have a static identity that an administrator assigns.
The use of groups allows you to define access for many users at one time. For example, an administrator can add 50 users to a group and then grant that group the role on a given resource. Each user in the group then receives the role.
Groups are managed in identity directories. For instructions, consult the Entitlements Administration Application help system.
Users are included in an authorization policy either through direct assignment or assignment by virtue of group or role membership. Each user within a directory must have a unique identity, or user name.
Users possess all attributes defined at the identity directory level. At the user-level, the value of these attributes can be modified as needed.
Users are managed in identity directories. For instructions, consult the Entitlements Administrative Application help system.
An identity directory may possess attributes that are inherited by its users and groups. An identity attribute is declared specifically to contain identity information. An attribute value can be used in policy definitions to set limits for that user. Attributes provide a very powerful way to refer to users and groups indirectly in policies, which results in a more dynamic and versatile policy set.
In the Entitlements Administrative Application, identity attributes are managed on the identity directory’s Attributes tab. For instructions, consult the Entitlements Administration Application help system.
You may tailor administrative access within an organization by setting up administrator roles with restricted rights. For example, one administrator role could be used to provide view-only access to an entire organization or to specific areas under it, another could restrict access to the management of identities, yet another allow management of applications only.
Once an administrator role is created, you define an administration role policy to assign the role to users.
Every organization has a built-in organization administrator role named OrgAdmin. When the organization is created, this role is assigned the same rights as the OrgAdmin role in the parent organization. This role's privileges can be changed, but not removed. By default, no user is assigned to this role.
Administrative privileges cascade downwards. The OrgAdmin role in a child organization cannot have more privileges than the OrgAdmin role in the parent organization. If the privileges of an OrgAdmin role are reduced, this reduction is also made to all administrative roles in the organization and any child organizations. (Note: Increasing OrgAdmin's privileges has no effect on other administrative roles.)
The privileges of any additional administrative roles you create in an organization cannot exceed those of the organization's OrgAdmin role.
Note: Administrative access to the applications in an organization can be further defined by using application administrators.
Administrator roles are managed under the organization. For instructions, consult the Entitlements Administration Application help system.
An application object serves as the management point for defining resources, actions, and application roles. Once these objects are defined, they are used as constituent parts of the policy definitions used to secure the application.
| Note: | Previous releases of this product did not provide an application object - the policy components for all secured applications were maintained in one flat structure. To provide support for backward compatibility, a reserved application (RootOrg/DefaultOrg/DefaultApp) has been provided to contain all policy components that were defined in previous versions. These components can continued to be managed as in previous releases. |
Application roles are defined at the application level and used to group access rights that may then distributed to users when they are granted the role. Once an application role is defined, a role policy can assign the role to subjects and an authorization policy can be used to define the role's access rights.
| Note: | Application roles are distinct from the new Application Administrator role which is used to set administrative rights managing an application in OES. |
The inheritance pattern of application roles is such that a subject assigned to a role (using a role policy) also inherits any child roles (so long as this is not prohibited by other role policies).
An application role may contain attributes and separation of duty constraints. Application role attributes can be used in role policy definitions to set conditions on whether or not a role is granted. Separation of duty constraints can be used to restrict assignment of a role based on the subject's current roles.
| Note: | The following application role names are defined in RootOrg/DefaultOrg/DefaultApp and cannot be changed: Admin Anonymous AuthenticatedUser Deployer Everyone Monitor Operator |
An administrator may define as many resources and levels in the hierarchy as needed to represent data, services, and system components within an application.
In the Entitlements Administrative Application, resources are managed under the application. For instructions, consult the Entitlements Administrative Application help system.
Resources may possess attributes that can be retrieved and evaluated when policies are enforced. Resources inherit all application attributes and modifications to these attributes. When an application attribute is removed, it is removed from all resources.
All resource attributes are inherited by child resources. Inherited resource attributes cannot be modified or removed.
Actions specify the access rights a user has on a resource. For instance, execute is a typical application action; and read and write are typical file system actions. A related collection of actions may be organized into a action group for management purposes.
To view the out-of-box actions and action groups, select the application in the left pane and click the Actions tab in the right pane.
In the Entitlements Administrative Application, actions and action groups are managed under the application. For instructions, consult the Entitlements Administrative Application help system.
The assignment to a role can be limited based on a number of items including the resource hierarchy, subjects (users and groups), constraints, and delegator. A role policy with the delegate action, delegates a role granted to one user (the delegator) on a resource to another user or group. A role cannot be delegated to a role.
In the Entitlements Administrative Application, role policies are managed under the application. For instructions, consult the Entitlements Administrative Application help system.
Authorization policies are typically written to grant specific actions upon specific resources with a defined set of constraints. An authorization policy can define actions, resources, subjects (users, groups, and roles), constraints, and delegators.
In the Entitlements Administrative Application, authorization policies are managed under the application. For instructions, consult the Entitlements Administrative Application help system.
Reports can be generated for both authorization and role policies. Authorization policy reports show who is granted or denied access a resource. Role policy reports show the subjects that are granted/denied a particular role.
An example of a role policy report is one that shows who can access a particular resource. If the report criteria specified the resource and the Grant effect, it would produce a complete list of the roles that will be granted to any subject during access to the defined resource. The inquiry could be narrowed by adding roles, subjects (users and groups) and delegators to the inquiry definition.
An authorization policy report could be used to determine who has a specific access right to a resource. The report would contain a complete list of the users for any subject for any role on the defined resource that has the specified action.
For instructions on generating role mapping policy reports, consult the Entitlements Administrative Application help system.
The policy simulation feature allows you to troubleshoot, test, and understand how policies are enforced on the SSM to which the application is bound.
For details about policy simulation, see Policy Simulation.
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 (for example, the date). To help you design efficient policies, various built-in extensions are provided for your use.
The three extension types are described in Extensions.
Application administrator roles can be set up with all or a subset of administrative rights in an application. This allows you to tailor administrative access as needed. For example, you may set up an administrator to create policies, but not be able to distribute them.
Once an administrator role is created, it can be assigned to users with a role policy.
By default, each application has an application administrator named AppAdmin will complete administrative access to the application.
To secure resources, both the SSM configuration and the policies must be deployed to the SSM being used to secure the application. Whenever configuration and policy changes are made, they must be distributed to the SSM.
To distribute policies to the SSM using the Entitlements Administrative Application:
To view the status of all policy distributions in an application, select the application in the left pane and click the Distribution tab in the application toolbar.
|
