21.3 Anatomy of an Application Domain and Policies

Access Manager enables you to control who can access resources based on policies defined within an Application Domain. Users attempt to access a protected resource by entering a URL in a browser, by running an application, or by calling some other external business logic. When a user requests access to a protected resource, the request is evaluated according to policies that discriminate between authenticated users who are authorized and those who are not authorized for access to a particular resource. Application domains do not have any hierarchical relationship to one another. Each Application domain can be made to contain policy elements related to an entire application deployment, a particular tier of the deployment, or a single host.

Within each Application Domain, specific resources are identified for protection by specific policies that govern access. Authentication and authorization policies include Administrator-configured responses that are applied upon successful evaluation. Authorization policies include Administrator-configured conditions and rules that define how evaluation is performed, and responses to be applied upon successful evaluation.

The size and number of Application Domains is up to the Administrator. The decision can be based on individual application resources or any other logical grouping as needed. An Application Domain is automatically created during Agent registration. Also, Administrators can protect multiple Application Domains using the same agent by manually creating the Application Domain and adding the resources and policies.

Figure 21-3 shows an expanded view of policies within an Application Domain, as well as how the shared elements are used in an Application Domain.

Figure 21-3 Anatomy of Access Manager Policies

Description of "Figure 21-3 Anatomy of Access Manager Policies"

For more information, see the following topics:

21.3.1 Resource Definitions for Policies

The term resource represents a document, or entity, or pieces of content stored on an OAM Server and available for access by a large audience.

Clients communicate with the OAM Server to request a resource using a particular protocol (HTTP or HTTPS, for example), which corresponds to an existing Resource Type. Every HTTP Resource Type must be associated with a host identifier. However, non-HTTP Resource Types are associated with a specific name (not a host identifier).

With Access Manager, each resource must be defined as within the Resources container in an Application Domain before it can be associated with a specific policy.

Note:

Only resources defined in the Resources container can be associated with policies in the Application Domain.

For more information, see "Adding and Managing Policy Resource Definitions".

Note:

To protect pieces of content on a page, Oracle recommends using Oracle Entitlements Server.

21.3.2 About Authentication Policies

Administrators can create an authentication policy to apply to specific resources within an Application Domain.

Each authentication policy:

Identifies the specific resources covered by this policy, which must be defined on the Resources tab of this policy and in the Resources container for the Application Domain
Specifies the authentication scheme that provides the challenge method to be used to authenticate the user
Specifies the Success URL (and the failure URL) that redirects the user based on the results of this policy evaluation
Defines optional Responses that identify post-authentication actions to be carried out by the Agent.

Policy responses provide the ability to insert information into a session and pull it back out at any later point. This is more robust and flexible than Oracle Access Manager 10g, which provided data passage to (and between) applications by redirecting to URLs in a specific sequence.

Policy responses are optional. These must be configured by an Administrator and are applied to specific resources defined within the Application Domain. For more information, see "Introduction to Policy Responses for SSO".

Authentication Policy Evaluation Results

To authenticate a user, Access Manager presents the user's browser with a request for authentication credentials based on the challenge method defined by the authentication scheme for this policy.

After policy evaluation, the result is returned and the user is redirected based on that result:

Success (allow access) redirects to the requested URL
Failure, (deny access) redirects to a generic error page

Note:

Policy evaluation results can be overridden policy by policy.

21.3.3 About Authorization Policies

Authorization is the process of determining if a user has a right to access a requested resource.

A user might want to see data or run an application program protected by a policy, for example.

Administrators can create an authorization policy to specify the conditions under which a subject or identity has access to a particular resource. The requested resource must belong to an Application Domain and must be included within a specific authorization policy.

Each authorization policy:

Identifies the specific resources covered by this policy, which must be defined on the Resources tab of this policy and in the Resources container for the Application Domain
Specifies the Success URL (and the failure URL) that redirects the user based on the results of this policy evaluation
Identifies specific Allow or Deny Rules based on defined conditions for this policy and resources. See Table 21-5 for an overview of Condition types.
Defines optional Responses that identify post-authorization actions to be carried out by the Agent, as described in "Introduction to Policy Responses for SSO".

21.3.4 About Token Issuance Policies

A Token Issuance Policy defines the rules under which a token can be issued for a resource (Relying Party Partner) based on the client's identity. The client can be either a Requester Partner or an end user.

Unless explicitly stated, information on Application Domains and authorization policies applies equally to Token Issuance policies.

Note:

During automatic policy generation, no Token Issuance Policies are created; only the container for Token Issuance Policies is generated automatically.

For specific information about Token Issuance Policies, see: