21.2 Access Manager Policy Model

Access Manager distills the policy models of Oracle Access Manager and OSSO into a single Access Manager policy model.

Figure 21-1 illustrates the main elements of the Access Manager 11g policy model including the shared policy components, an individual Application Domain, and external dependencies.

Figure 21-1 Access Manager 11g Policy Model

Description of "Figure 21-1 Access Manager 11g Policy Model "

Shared Policy Components

Shared policy components are global and can be used in one or more Application Domains. Figure 21-2 illustrates the shared components for Access Manager policies.

Figure 21-2 Access Manager Shared Policy Components

Description of "Figure 21-2 Access Manager Shared Policy Components"

Table 21-3 describes the global, shared components in an Access Manager policy.

Table 21-3 Access Manager Global, Shared Policy Components

Component	Description
Resource Types	Defines the type of resource to be protected and the associated operations. The default resource type is HTTP. However, Administrators can define non-HTTP resource types that can be applied to specific resources in an Application Domain. Any number of resources can belong to a specific resource type. However, each resource that is added to a policy must be defined as a single type: HTTP wl_authen TokenServiceRP See Also: Managing Authentication and Shared Policy Components: Managing Resource Types Managing Templates, Endpoints, and Policies: Managing TokenServiceRP Type Resources
Host Identifiers	A host can be known by multiple names. To ensure that OAM recognizes the URL for a resource, OAM must know the various ways used to refer to that resource's host computer. With Access Manager, all possible host variations are stored together. Administrators enter the canonical name for the host and every other name by which the host can be addressed by users. A request sent to any address on the list is mapped to the official host name. Authentication and authorization policies in an Application Domain protect resources based on host identifiers. Host identifiers are used to identify resources or an application at run time and can be used to formulate policies for application resources at design time. Host identifiers can be generated automatically during Agent registration and are used to seed the Resource definition and default authentication and authorization policies in the new Application Domain. Alternatively: Administrators can create a host identifier definition for use in one or more Application Domains. Virtual Web Hosting: Enables support of multiple domain names and IP addresses that each resolve to their unique subdirectories on a single server. The same host can have multiple sites being served either based on multiple NIC cards (IP based) or multiple names (for example, abc.com and def.com) resolving to same IP. See Also: "About Host Identifiers".
Authentication Scheme	A named component that defines the challenge mechanism, level of trust, and the underlying authentication module or plug-in required to authenticate a user. Several default schemes provided with Access Manager and Administrators can define their own schemes. Authenticating a user's identity with Access Manager refers to running a pre-defined set of processes to verify the digital identity of the user. One authentication scheme can be assigned to multiple authentication policies. However, each authentication policy can have only one authentication scheme assigned to it. Note: Authentication schemes are defined globally to ensure that a small number of Administrators define them in a consistent, secure way. See Also: "Managing Authentication Schemes"
Authentication Modules and Plug-ins	The smallest executable unit of an authentication scheme. The authentication module determines the exact procedure to be followed and the method for challenging the user for credentials. Authentication involves determining which credentials a user must supply when requesting access to a resource, gathering credentials, and returning a response that is based on the results of credential validation. All authentication processing relies on an authentication module to define the rules governing requirements and transmission of information to the backend authentication scheme. All information collected by the plug-in and saved in the context is available to the plug-in through the authentication process. Context data can also be used to set cookies or headers in the user's login page A number of plug-ins and several pre-defined modules are provided. Oracle strongly recommends using plug-ins, which you can configure and orchestrate as needed to provide multi-step authentication. See Also: "Managing Native Authentication Modules" "Orchestrating Multi-Step Authentication with Plug-in Based Modules"

Access Manager Policy Components

Access Manager default behavior denies access when a resource is not protected by a policy that explicitly allows access. Table 21-4 describes policy components you configure to allow access and where you can find the details.

Table 21-4 Access Manager Policy Components

Component	Description
Application Domain	Each Application Domain provides a logical container for resources, and the associated policies that dictate who can access these resources. An application domain can be created automatically during Agent registration or manually using the console. See Also: "Anatomy of an Application Domain and Policies"
Resource Definitions	Based on a defined host identifier, Administrators can add specific resources to an Application Domain and apply policies to protect those resources. See Also: "Adding and Managing Policy Resource Definitions".
Authentication Policy	Each resource defined in an Application Domain can be protected by only one authentication policy. Each authentication policy requires one authentication scheme. One authentication policy can protect many resources. However, each resource can be protected by only one authentication policy. See Also: "Defining Authentication Policies for Specific Resources"
Authorization Policies	Each resource assigned to an Application Domain can be protected by only one authorization policy. Each policy can include one or more conditions and a rule. Authorization policies can also contain success responses. One authorization policy can protect many resources. However, each resource can be protected by only one authorization policy. See Also: "Defining Authorization Policies for Specific Resources".
Token Issuance Policy	By default, only a container for Token Issuance Policies is provided in a generated Application Domain. No Conditions or Rules are generated automatically. You must add these manually. See Also: "Token Issuance Policy Pages".
Policy Responses	Available for all policy types, Authentication and Authorization success Responses can be defined within respective policies to be applied after policy evaluation. See Also: "Introduction to Policy Responses for SSO".
Rule	Available for only Authorization and Token Issuance Policies. Each Authorization policy includes a rule that defines whether the policy allows or denies access to resources protected by the policy. The rule references Authorization conditions, described next. See Also: "Introduction to Authorization Policy Rules and Conditions".
Condition	Available for only Authorization and Token Issuance Policies. Each Authorization policy rule references conditions that define to whom the rule applies, if there is a time Condition, and how evaluation outcomes are to be applied. Conditions are declared outside of rules and are referenced within a rule. See Also: "Introduction to Authorization Policy Rules and Conditions".