OAM Application Domain and Policy Objects

Below is a big picture that explains Oracle Access Manager OAM's Application Domain and Conceptual relationships for Policy Objects.

Application Domain:
An application domain consists of four big buckets:
Resources that need to be protected for access,
Authentication Policies that check users for valid authentication,
Authorization Policies that determine the access to those resources, and
Token Issuance Policy that defines the rules under which a token can be issued for a resource (Relying Party Partner) based on the client's identity, with the client either being a Requester Partner or an end user.

The resources you specify in Authentication, Authorization, and Token policies must be one of the resources defined under the resource bucket within the application domain.

You can have N number of resources, authentication, authorization and Token Policies specified in an application domain.

Conceptual Relationships for Policy Objects
All 1:M relationships are Optional:Required, respectively (required toward the crow's foot end), except the relationship between the Authentication module and identity store, which is optional at both ends (because the identity store association is only in the case of the Authentication modules requiring LDAP).

Identity Store and Authentication module are part of System Configuration even though they are shown here for completeness of relationships.

The top-level construct of the Oracle Access Manager 11g Policy model is the OAM application domain. Each application domain provides a logical container for resources (or sets of resources), and the associated authentication and authorization policies that dictate who can access specific resources.

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 doamin is automatically created during agent registration. Also, administrators can protect multiple application domains by using the same agent by manually creating the application domain and adding the resources and policies.

After a policy has been evaluated, tow standard actions are performed:

• The result is returned.
• The user is shown something based on that result: either the requested URL requested (on SUCCESS, allow) or the URL of a generic error page (on FAILURE, deny)

Either or both results can be overridden on a policy-by-policy basis.

Policy Responses for SSO 
Administrator-defined policy responses declare optional actions to be taken in addition to the above. Policy responses provide the ability to insert information into a session and pull it back out at any later point.
An authorization rule and conditions grant or deny access to a particular resource based on the context of the request for that resource. Authorization rules define the obligations (requirements) that must be fulfilled before responding to a client's request. Evaluation of rules determines whether the authorization policy applies to the incoming request. The appropriate obligations that effect after successful authentication.
Evaluation of the authorization policy results in one of two outcomes: SUCCESS (allow) or FAILURE (deny). If the data is insufficient to evaluate the policy, the outcome is always FAILURE. For example, if the value of a user attribute is evaluated by a rule, but the attribute is not set for that user, the outcome is FAILURE.

OAM Console URL: http://servername:7021/oamconsole

For any further queries to use Oracle Access Manager OAM to enable Single Sign On SSO for E-Business Suite application, please don't hesitate to contact me on samiappsdba@gmail.com