15 Introduction to Single Sign-On with Access Manager

This chapter introduces elements of Access Manager single sign-on to provide a foundation of knowledge before you begin developing policies. This chapter includes the following topics:

• Introduction to Access Manager Single Sign-On

• Understanding the Access Manager Policy Model

• Anatomy of an Application Domain and Policies

• Introduction to Policy Conditions and Rules

• Introduction to Access Manager Credential Collection and Login

• Understanding SSO Cookies

• Introduction to Configuration Tasks for Single Sign-On

Note:

Unless explicitly stated, information in this chapter is the same for all agent types and Access Manager credential collectors.

For details about single log-out, see Chapter 19, "Configuring Centralized Logout for Sessions Involving 11g Webgates".

15.1 Introduction to Access Manager Single Sign-On

Login is the action the user takes to authenticate and gain access to a desired application. Single sign-on (SSO) is a process that gives users the ability to access multiple protected resources (Web pages and applications) with a single authentication. SSO is enabled by Access Manager to eliminate the need for additional or different logins to access other applications at the same (or lower) authentication level during the same session.

Access Manager converges SSO architectures such as Identity Federation for Partner Networks, and Service Oriented Architecture (SOA), to name a few. Access Manager provides single sign-on (SSO) through a common SSO Engine that provides consistent service across multiple protocols.

Oracle Identity Management Infrastructure enables secure, central management of enterprise identities:

• User identities are stored in the identity store referenced in the policy.

• Contextual data is the information that is either presented to or collected by OAM Server at various stages of user interaction. These stages include authentication, authorization, enterprise single sign on, federation, adaptive authentication, token validation, session creation, and so on. The information itself might comprise a user's device fingerprints, IP address, antivirus and firewall protection, assertion and so on.

  Components that play the role of contextual data providers and asserters when integrated with Access Manager include Enterprise Single Sign-on, Identity Federation, Oracle Adaptive Access Manager.

Table 15-1 summarizes the components that support or enforce Access Manager policies, and where to find more information about these, if needed.

Note:

Default Access Manager behavior is to deny access when a resource is not protected by a policy that explicitly allows access. To delegate authentication tasks to Access Manager, agents must reside with the relying parties and must be registered with Access Manager. Registering an agent sets up the required trust mechanism between the agent and Access Manager SSO.

Table 15-1 Summary: SSO Components

Component	Description
Applications	Applications can delegate authentication and authorization to Access Manager and accepts headers from a registered Agent. Note: External applications do not delegate authentication. Instead, these display HTML login forms that ask for application user names and passwords. For example, Yahoo! Mail is an external application that uses HTML login forms.
OAM Server Oracle Access Management Console (installed on WebLogic AdminServer)	Non-administrative users first gain access by entering the URL of a protected resource, which returns the SSO login page. See Also: "Introduction to Access Manager Credential Collection and Login". Administrative users access the console to author policies by typing the URL: https://host:port/oamconsole. Although, default policies can be generated automatically during Agent registration, as described in Chapter 13. See Also: Chapter 17, "Managing Policies to Protect Resources and Enable SSO".
Policy Enforcement Agents	OAM Agents (Webgate or Access Client) Legacy OSSO Agents Legacy OpenSSO Agents See Also: Chapter 12, "Introduction to Agents and Registration".
Credential Collectors and Communication Channels	Authentication with the default embedded credential collector (ECC) occurs across the HTTP (HTTPS) channel Authentication with the optional detached credential collector (DCC) occurs across the Oracle Access Protocol (OAP) channel Authorization occurs across the Oracle Access Protocol (OAP) channel See Also: Table 16-5, "Comparing the DCC and ECC"
SSO Engine	Manages the session lifecycle, facilitates global logout across all relying parties in the valid session, and provides consistent service across multiple protocols. See Also: Chapter 14, "Managing Sessions" and Chapter 19, "Configuring Centralized Logout for Sessions Involving 11g Webgates"
Proxy support for legacy systems	OAM Proxy supports legacy Access Manager implementations by acting as a legacy Access Server. See: "Managing the Access Protocol for OAM Proxy Simple and Cert Mode Security" "Introduction to OAM Proxy Metrics and Tuning" OSSO Proxy supports OSSO Agents by acting as the legacy OSSO Server. See: Chapter 21 Oracle-provided OpenSSO Proxy handles requests for resources protected by OpenSSO Agents. See: Chapter 20 See Also: About the Embedded Proxy Server and Backward Compatibility
Access Policies	Registered agents rely on Access Manager authentication, authorization, and token issuance policies to determine who gets access to protected applications (defined resources). Note: Default Access Manager behavior is to deny access when a resource is not protected by a policy that explicitly allows access. See Also: Chapter 17, "Managing Policies to Protect Resources and Enable SSO"
Policy Store	Database in production environments (otherwise, oam-config.xml). See Also: Chapter 4
Cryptographic keys and Key Storage	One key is generated and used per registered mod_osso or 11g Webgate. However, one single key is generated for all 10g Webgates. See Also: Table 1-3, "Introduction: Access Manager 11.1.2".
Cookies	See: "Understanding SSO Cookies".

Note:

Single Sign-on for the Oracle Access Management Console, and other Oracle Identity Management consoles deployed in a WebLogic container, is enabled using the pre-registered IAMSuiteAgent and companion policies. No further configuration is needed to protect the consoles.

Single sign-on can be implemented as introduced in Table 15-2, which includes pointers to additional information.

Table 15-2 Introduction to SSO Implementations

SSO Type	Description
Single Network Domain SSO	You can set up Access Manager single sign-on for resources within a single network domain (example.com, for example). This includes protecting resources belonging to multiple WebLogic administration domains within a single network domain. Single Network Domain SSO is the subject of this book.
Multiple Network Domain SSO	Access Manager 11g supports cross-network-domain single sign-on out of the box. See Also:"About Multiple Network Domain SSO".
Application SSO	Application single sign-on allows users who have been authenticated by Access Manager to access applications without being re-authenticated. See Also: "About Application SSO and Access Manager"
Multiple WebLogic Server Domain SSO	The basic administration unit for WebLogic Server instances is known as a domain. You can define multiple WebLogic administration domains based on different system Administrators' responsibilities, application boundaries, or the geographical locations of WebLogic servers. However, all Managed Servers in a cluster must reside in the same WebLogic Server domain. See Also: "About Multiple WebLogic Server Domain SSO"
Reverse-Proxy SSO	This SSO implementation type is supported with a few configuration differences. See Also: "About Reverse-Proxy SSO"
SSO with Mixed Release Agents	Access Manager seamlessly supports registered 11g and 10g OAM gents (Webgates and programmatic access clients), as well as legacy OSSO Agents (mod_osso 10g), and legacy OpenSSO agents). These can be used in any combination.

15.1.1 About Multiple Network Domain SSO

With Access Manager, this is a standard feature. When 11g Webgates are used exclusively all cookies in the system are host-based. However, you must have control over all the domains. If some domains are controlled by external entities (not part of the Access Manager deployment), Oracle recommends that you use Identity Federation.

Access Manager supports cross-network-domain single sign-on out of the box. During single sign-off with Access Manager:

• The SSO cookie set by OAM Server is a host cookie that works across the network domains. The Webgate clears its standalone Agent cookie and then redirects to the OAM Server for session clearing.

• 10g Webgates do not have a standalone Agent cookie; logout occurs only on the server side with no redirection required.

• With 11g Webgates and OSSO agents that support a standalone agent cookie, the agent Logout Callback URL is called in parallel. The agents accessed in a session and agents from multiple domains are all called in parallel, depending on the number of concurrent connections supported in the browser.

Note:

Access Manager provides a proprietary multiple network domain SSO capability that predates Identity Federation 11.1.1. If this is implemented in your Oracle Access Manager 10g deployment, you can register 10g Agents with Access Manager 11g to continue this support.

See Also:

• "Configuring Centralized Logout for 11g Webgates"

• Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation, 11.1.1

15.1.2 About Application SSO and Access Manager

Access Manager enables Administrators to create a web of trust in which a user's credentials are verified once and are provided to each application the user runs. Using these credentials, the application does not need to re-authenticate the user with its own mechanism.

Application single sign-on allows users who have been authenticated by Access Manager to access applications without being re-authenticated.

There are two ways to send a user's credentials:

• Using Cookies: A specific value is set on the browser's cookie that the application must extract to identify a user.

• Using Header Variables: An HTTP header set on the request by the agent and visible to the application.

Note:

Both forms require Administrators to enter the appropriate responses within the policy. For more information, see "Introduction to Policy Responses for SSO".

Header response values are inserted into a request by an OAM Agent, and can only be applied on Web servers that are protected by an agent. registered with Access Manager 11g If the policy includes a redirect URL that is hosted by a Web server not protected by Access Manager, header responses are not applied.

For example, when a user authenticates, she might be redirected to a portal index page:

http://example.com/authnsuccess.htm

For authentication failure, an authentication action might redirect the user to an error page or a self-registration script:

http://example.com/authnfail.htm

15.1.3 About Multiple WebLogic Server Domain SSO

Access Manager supports SSO in multiple WebLogic administration domains.

You can define multiple WebLogic administration domains based on different system Administrators' responsibilities, application boundaries, or the geographical locations of WebLogic servers. Conversely, you can use a single domain to centralize all WebLogic Server administration activities.

Note:

All Managed Servers in a cluster must reside in the same domain; you cannot split a cluster over multiple domains. All Managed Servers in a domain must run the same version of the Oracle WebLogic Server software. The Administration Server can run either the same version as the Managed Servers in the domain, or a later service pack.

There are two basic types of WebLogic administration domains:

• Domain with Managed Servers: A simple production environment can consist of a domain with several Managed Servers that host applications, and an Administration Server to perform management operations. In this configuration, applications and resources are deployed to individual Managed Servers; similarly, clients that access the application connect to an individual Managed Server.

  Production environments that require increased application performance, throughput, or availability may configure two or more of Managed Servers as a cluster. Clustering allows multiple Managed Servers to operate as a single unit to host applications and resources. For more information about the difference between a standalone and clustered Managed Servers, see Managed Servers and Clustered Managed Servers.

• Standalone WebLogic Server Domain: For development or test environments, you may want to deploy a single application and server independently from servers in a production domain. In this case, you can deploy a simple domain consisting of a single server instance that acts as an Administration Server and also hosts the applications you are developing. The examples domain that you can install with WebLogic Server is an example of a standalone WebLogic Server domain.

All Managed Servers in a cluster must reside in the same domain; you cannot split a cluster over multiple domains. All Managed Servers in a domain must run the same version of the Oracle WebLogic Server software. The Administration Server can run either the same version as the Managed Servers in the domain, or a later service pack.

Each domain's configuration is stored in a separate configuration file (config.xml), which is stored on the Administration Server along with other files such as logs and security files. When you use the Administration Server to perform a configuration task, the changes you make apply only to the domain managed by that Administration Server. To manage another domain, use the Administration Server for that domain. For this reason, the servers instances, applications, and resources in one domain should be treated as being independent of servers, applications, and resources in a different domain.You cannot perform configuration or deployment tasks in multiple domains at the same time.

Each domain requires its own Administration Server for performing management activities. When you use the Oracle Access Management Console to perform management and monitoring tasks, you can switch back and forth between domains, but in doing so, you are connecting to different Administration Servers.

If you have created multiple domains, each domain must reference its own database schema. You cannot share a configured resource or subsystem between domains. For example, if you create a JDBC data source in one domain, you cannot use it with a Managed Server or cluster in another domain. Instead, you must create a similar data source in the second domain. Furthermore, two or more system resources cannot have the same name.

15.1.4 About Reverse-Proxy SSO

This is a supported configuration with the following caveats.

Caveats

If you are going to use a reverse proxy in a single sign-on configuration, be sure to perform one of the following tasks. Otherwise, the reverse proxy hides the client's IP address:

• Either to set the IPvalidation parameter to false

• Or add the proxy IP address to the IPValidationExceptions list in the Webgate registration

In some situations the Reverse Proxy does not pass the 10g Webgate ObSSOCookie to Oracle WebLogic after a successful authentication. To avoid this issue:

• Use Form authentication instead of Basic Over LDAP when using Reverse Proxy with Oracle WebLogic

• For 11g Webgate, a user-defined parameter (filterOAMAuthnCookie (default true)) can be used to prevent the OAMAuthnCookie from being passed to downstream applications for security consideration. If you do want to pass the cookie on, then set the filterOAMAuthnCookie parameter to false.

15.2 Understanding the Access Manager Policy Model

Access Manager distills the policy models of Oracle Access Manager and OSSO into a single model. This section introduces the Access Manager 11g policy model.

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

Figure 15-1 Access Manager 11g Policy Model

Description of "Figure 15-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 15-2 illustrates the shared components for Access Manager policies.

Figure 15-2 Access Manager Shared Policy Components

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

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

Table 15-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: Chapter 16: Managing Resource Types Chapter 34: 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 15-4 describes policy components you configure to allow access and where you can find the details.

See Also:

"Anatomy of an Application Domain and Policies"

Table 15-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 Resource Definitions to be Added to Policies".
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: "About 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".

15.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 15-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 15-3 Anatomy of Access Manager Policies

For more information, see the following topics:

• About Resource Definitions for Policies

• About Authentication Policies

• About Authorization Policies

• About Token Issuance Policies

15.3.1 About 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 Resource Definitions to be Added to Policies".

Note:

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

15.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.

See Also:

• "About Authentication Policy Pages"

• "Managing Run Time Policy Evaluation Caches"

15.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.

Note:

OracleAS SSO 10g does not provide authorization; OSSO Agents do not use Access Manager 11g Authorization Policies.

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 15-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".

See Also:

"Introduction to Policy Conditions and Rules"

15.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:

• "Managing TokenServiceRP Type Resources"

• "Managing Token Issuance Policies, Conditions, and Rules"

15.4 Introduction to Policy Conditions and Rules

Unless explicitly stated, information on policy Conditions and Rules applies equally to:

• Authorization policies

• Token Issuance policies

Conditions

Conditions can be specified only within Authorization and Token Issuance policies. Conditions are used in conjunction with Rules that specify Allow or Deny access, based on defined Conditions. Table 15-5 identifies available condition types.

Table 15-5 Condition Types

Type	For more information, see ...
Identity	"Introduction to Authorization Policy Rules and Conditions".
IP4 Range	"Defining IP4 Range Conditions".
Temporal	"Defining Temporal Conditions".
Attribute	"Defining Attribute Conditions".
True	Effectively "Allow All". Oracle recommends this be used as the default option in cases where you need to let in any authenticated use. In this case, you do not need any particular conditions to be satisfied at authorization time. This replaces the Use Implied Constraints flag the previous release of Access Manager, which similarly lets policy evaluation complete with an Allow result when no specifically-defined constraints were present.

Each Authorization and Token Issuance policy can contain one or more condition objects. There can be more than one instance of a type of condition in a policy (the previous policy model allowed only one instance of a class in a policy).

Conditions are similar to earlier Access Manager 11g authorization constraints. However, constraints included Allow or Deny specifications and conditions do not.

Rules

Rules are new constructs in the policy model. Each Rule defines the Allow or Deny specification that determines the overall effect of the policy. Rules also define how the outcomes of each Condition evaluation is to be combined. Conditions are referenced in rules and declared outside of rules.

Within a Rule, evaluation outcomes can be combined as follows:

• Simple Mode: Accepts a list of condition names that are combined based on the value of a combiner that allows either All conditions to be met or Any one condition to be met to return "true" for the evaluation. [Previously, ALL allowed constraints while ANY denied them.]

• Expression mode: Allows the user to specify a Boolean expression to combine conditions using condition names and special characters (comma, vertical bar, ampersand and exclamation point: , |& and !.

Note:

A policy in which there are one or more conditions that are not part of either an Allow or Deny Rule is treated as a valid policy.

For more information about Conditions and Rule, see Chapter 17.

15.5 Introduction to Access Manager Credential Collection and Login

This section provides the following topics:

• About Access Manager Credential Collection

• About SSO Login Processing with OAM Agents and ECC

• About Login Processing with OAM Agents and DCC

• About SSO Login Processing with OSSO Agents (mod_osso) and ECC

15.5.1 About Access Manager Credential Collection

Access Manager provides two mechanisms for credential collection during authentication processing:

• The default Embedded Credential Collector (ECC) is installed with the OAM Server and can be used as-is with no additional installation or set up steps (except the global password policy configuration described in "Managing Global Password Policy").

  The mechanism that redirects the user from the Policy Enforcement Point to the Credential Collector is a proprietary front channel protocol over HTTP. This protocol currently provides a context of the request and the authentication response on the query string.

• The 11.1.2 (or later) Webgate provides a single switch for the optional Detached Credential Collector (DCC). The DCC provides network isolation for greater security in production deployments, and is required for some forms of authentication.

Unless explicitly stated, instructions in this book presume you are using the ECC.

Single Sign On login processing determines whether the user is a valid user and whether the session state is active or inactive (either a first time user or the user session has expired). Session management support locates, persists, and cleans up the session context and user token.

Login with Self-Service Provisioning Applications

Provisioning does not create the session in Access Manager. When a new user uses a self-service provisioning application to create an account, he is prompted for his userID and password again when accessing an application.

The protected application is directed to Access Manager 11g, which requests the user's credentials. For example, if Oracle Identity Manager is protected by Access Manager, the user request is redirected to Access Manager from which a request to enter credentials is made.

Success and failure results are the same as described in "Login Processing with Access Manager-Protected Resources".

Login Processing with Access Manager-Protected Resources

The first time a user attempts to access a protected resource, she is prompted for her credentials based on the authentication scheme and authentication level for the resource. Typically a userID and password are needed.

Failure: Authentication fails if the wrong userID or password is entered. The user is not authenticated and another prompt for credentials appears.

With Oracle Access Manager 11.1.1, only the credential collector embedded in the OAM server was available (embedded credential collector (ECC)). Access Manager 11.1.2 supports the ECC by default. However, Access Manager also enables you to configure an 11g Webgate to use as a detached credential collector (DCC). A DCC-enabled Webgate can be separate from (or combined with) a Resource Webgates.

The DCC is considered more secure when compared to the default embedded credential collector (ECC).

Both the ECC and DCC provide an authentication flow that includes form login, error, and login retries. Both the ECC and DCC provide SecurID and server affinity as well as password policy enforcement.

Both the ECC and DCC provide a dynamic, multi-step, iterative, and variable (multi-step authentication) where the credentials are not supplied all at one time. A customizable authentication flow can include authentication plug-ins with contracts between the plug-in, OAM Proxy, and Credential Collector; a contract between the plug-in and login application; and between the Credential Collector and login application.

When deciding whether to use one credential collector or both, condsider:

• Co-existence: Allowing both the ECC and DCC to co-exist enables you to use authentication schemes and policies configured for either the ECC or the DCC. This enables a fallback mechanism for resources that rely on the ECC (Oracle Access Management Console, for instance).

• Disabling ECC: Disabling the ECC entirely prohibits access to resources that rely on the ECC mechanism (Oracle Access Management Console, for instance).

Table 15-6 provides links to more information.

Table 15-6 Login Processing with Access Manager-Protected Resources

Login Processing Topic	See
With OAM Agents and ECC	"About SSO Login Processing with OAM Agents and ECC"
With OAM Agents and DCC	"About Login Processing with OAM Agents and DCC"
With OSSO Agents and ECC	"About SSO Login Processing with OSSO Agents (mod_osso) and ECC"
With Other Agents or Mixed Agent Types	Mixed agent types are supported. Processing is the same for each agent type. For other agent types, see: Chapter 20, "Registering and Managing Legacy OpenSSO Agents" Chapter 21, "Registering and Managing Legacy OSSO Agents" Chapter 22, "Registering and Managing 10g Webgates with Access Manager 11g"
Login and Auto Login for Applications Using Oracle ADF Security	Oracle Platform Security Services (OPSS) comprise Oracle WebLogic Server's internal security framework. On the Oracle WebLogic Server, you can run a Web application that uses Oracles Application Development Framework (Oracle ADF) security, integrates with Access Manager 11g SSO, and uses OPSS SSO for user authentication. For more information, see Appendix A, "Integrating Oracle ADF Applications with Access Manager SSO".

15.5.2 About SSO Login Processing with OAM Agents and ECC

This topic is based on using the default Embedded Credential Collector with OAM Agents (Resource Webgates) protecting resources).

Access Manager authenticates each user with a customer-specified authentication method to determine the identity and leverages information stored in the user identity store. Access Manager authentication supports several authentication methods and a number of authentication levels. Resources with varying degrees of sensitivity can be protected by requiring higher levels of authentication that correspond to more stringent authentication methods.

When a user tries to access a protected application, the request is received by Access Manager which checks for the existence of the SSO cookie.

After authenticating the user and setting up the user context and token, Access Manager sets the SSO cookie and encrypts the cookie with the SSO Server key (which can be decrypted only by the SSO Engine).

Depending on the actions (responses in Access Manager 11g) specified for authentication success and authentication failure, the user may be redirected to a specific URL, or user information might be passed on to other applications through a header variable or a cookie value.

Based on the authorization policy and results of the check, the user is allowed or denied access to the requested content. If the user is denied access, she is redirected to another URL (specified by the Administrator in Webgate registration).

Figure 15-4 shows the processes involved in evaluating policies, validating a user's identity, authorizing the user for a protected resource, and serving the protected resource. This example shows the OAM Agent flow. There are slight variations with 11g Webgates/Access Clients.

Figure 15-4 SSO Log-in with Embedded Credential Collector and OAM Agents

Description of "Figure 15-4 SSO Log-in with Embedded Credential Collector and OAM Agents"

Process overview: SSO Login Processing with Embedded Credential Collector and OAM Agents

1. The user requests a resource.

2. Webgate forwards the request to Access Manager for policy evaluation.

3. Access Manager:

   • Checks for the existence of an SSO cookie.

   • Checks policies to determine if the resource protected and if so, how?

4. Access Manager Server logs and returns decisions.

5. Webgate responds as follows:

   1. Unprotected Resource: Resource is served to the user.

   2. Protected Resource:

      Request is redirected to the credential collector.

      The login form is served based on the authentication policy.

      Authentication processing begins

6. User sends credentials.

7. Access Manager verifies credentials.

8. Access Manager starts the session and creates the following host-based cookies:

   • One per Agent: OAMAuthnCookie set by 11g Webgates (ObSSOCookie set by 10g Webgate) using the authentication token received from the OAM Server after successful authentication.

     Note: A valid cookie is required for a session.

   • One for OAM Server: OAM_ID

9. Access Manager logs Success or Failure.

10. Credential collector redirects to Webgate and authorization processing begins.

11. Webgate prompts Access Manager to look up policies, compare the user's identity, and determine the user's level of authorization.

12. Access Manager logs policy decision and checks the session cookie.

13. OAM Server evaluates authorization policies and cache the result.

14. OAM Server logs and returns decisions

15. Webgate responds as follows:

    • If the authorization policy allows access, the desired content or applications are served to the user.

    • If the authorization policy denies access, the user is redirected to another URL determined by the Administrator.

15.5.3 About Login Processing with OAM Agents and DCC

The detached credential collector is simply a WebGate configured to use the additional Credential Collection capability in your deployment. There are two deployment types depending on whether the DCC WebGate is also protecting the applications or not.

Table 15-7 identifies the DCC-supported deployments.

Table 15-7 DCC Deployment Support

Deployment Type	Description
Separate DCC and Resource Webgate	A distributed deployment where WebGates protecting applications are managed independently from the centralized DCC. You can have: Two or more 11.1.1.5 Resource Webgates that redirect to the 11.1.2 DCC-enabled Webgate for authentication 10.1.4.3 Resource Webgate that redirects to the 11.1.2 DCC-enabled Webgate for authentication Enable HTTPS between the user-agent and the DCC (but not with some or all Resource WebGates). When credential collection is externalized and centralized in the DCC, the user-agent connections with other WebGates never carry user credentials, nor session tokens that could be used to obtain access to resources protected by any other WebGate. This significantly reduces exposure caused by lack of SSL on these links and may be an acceptable tradeoff in some deployments. Separate OHS Instances: Install the DCC on a different OHS instance (on the same or different host) as the Resource Webgate. Define the Resource Webgate Authentication Scheme Challenge Redirect URL to point to the DCC. Define the Resource Webgate logoutRedirectUrl to point to the DCC logout script/page (logout callbacks to Resource Webgate is invoked during logout). See Also: Figure 15-5
Combined DCC and Resource Webgate	A streamlined deployment minimizing configuration and processing overhead. A DCC Webgate can function as both a resource Webgate (Policy Enforcement Point) that protects application resources and a DCC. In this case, there is no front-channel redirection or processing: Install the DCC on a the same OHS instance (on the same host) as the Resource Webgate. Simplified configuration: The Challenge Redirect URL can be empty. No logoutRedirectUrl is needed, no logout callback is needed. See Also: Figure 15-6

Separate DCC and Resource Webgates: A sample deployment with segregated DCC is shown in Figure 15-5.

Figure 15-5 Example: Separate Resource Webgate and DCC Webgate Deployment

This topology (Figure 15-5) showcases choices appropriate for scenarios with maximum security sensitivity. Both centralized and externalized credential collection are used: Resource WebGates protecting applications are segregated from the DCC WebGate performing credential collection.

The user accesses the Access Manager-protected resource from the public network. A WebGate protecting the application is deployed within a DMZ. The DCC Webgate is also deployed within a DMZ. The protected application and OAM Server instances are located within the private network and not directly accessible from the public network.

Using the DCC in the DMZ, only authenticated network connections are allowed to reach the server itself. The DCC inherits all back-channel communication characteristics available to 11g WebGates (network connection using the Oracle Access Protocol). The OAP offers:

• SSL between the client and the server, optionally using 3rd party signed certificates

• mutual authentication at the application level using client id and password

• request multiplexing and full-duplex communication at the application level

• built-in connection load balancing and failover capability

The DCC receives an authentication request from the Agent and checks for the presence of the DCC cookie. If the cookie does not exist, credential collection is initiated; checks are made, and user-supplied credentials are passed for validation.

Note:

Encryption occurs only from an 11g resource Webgate to the DCC. The channel is not encrypted for communication between 10g resource Webgate and 11g DCC; this is in clear text.

Figure 15-6 Combined DCC and Webgate Configuration

Process overview: Authentication with the combined DCC and Resource Webgate

1. The user requests access to a resource which initiates the authentication process.

2. The DCC redirects through the front channel to the login page.

3. The login page is returned to the user.

4. User enters credentials, which are posted to the action URL (a user-defined parameter in an authentication scheme, Table 16-22).

5. Authentication occurs using the back channel (OAP) and OAM Proxy.

6. The Authentication Plug-in is activated.

7. The Plug-in requests redirect to a URL to collect additional credentials.

8. The Plug-in request is returned to the DCC.

9. The DCC redirects to the URL and expects specified credentials.

10. The Browser follows the redirect.

11. Credentials are posted to the Action URL.

See Also:

"Configuring Logout When Using Detached Credential Collector-Enabled Webgate"

15.5.4 About SSO Login Processing with OSSO Agents (mod_osso) and ECC

SSO login processing with registered OSSSO Agents (mod_osso) is similar to login processing with Webgates. However, mod_osso provides only authentication using Access Manager 11g authentication policies.

Note:

mod_osso does not support authorization either on its own or using Access Manager 11g policies.

Figure 15-7 illustrates the login processing with mod_osso and Access Manager 11g.

Figure 15-7 SSO Login Processing with OSSO Agents and ECC

Description of "Figure 15-7 SSO Login Processing with OSSO Agents and ECC"

Process overview: SSO Log-in Processing with OSSO Agents and ECC

1. The user requests a resource.

2. mod_osso forwards the request to Access Manager for policy evaluation.

3. Access Manager:

   • Checks for the existence of an SSO cookie.

   • Checks policies to determine if the resource protected and if so, how?

4. OAM Server logs and returns decisions.

5. mod_osso responds as follows:

   1. Unprotected Resource: Resource is served to the user.

   2. Protected Resource:

      Request is redirected to the credential collector.

      The login form is served based on the authentication policy.

      Authentication processing begins

6. User sends credentials.

7. ECC verifies credentials.

8. Access Manager starts the session, passes an authentication token to the application, and creates the following cookies:

   • One per partner: OHS_host_port

   • One for the OAM Server: OAM_ID

   • Global Inactivity Out: A domain-level cookie GITO, described in "mod_osso Cookies"

9. Access Manager logs Success or Failure.

10. Credential collector redirects to mod_osso, which transmits the simple header values that applications can use to authorize the user.

11. Resource is served upon authentication success and the OHS-host-port cookie is set.

15.6 Understanding SSO Cookies

This section provides a brief overview of single sign-on with Access Manager 11g. It includes the following topics:

• About Single Sign-On Cookies During User Login

• About Single Sign-On Server and Agent Cookies

15.6.1 About Single Sign-On Cookies During User Login

Table 15-8 describes the cookies that can be set or cleared during user login.

Table 15-8 SSO Cookies

SSO Cookie Set at User Login	Set By	Description
OAM_ID cookie	OAM Server Embedded Credential Collector	When a user attempts to access a protected application, the request comes to the SSO Engine and the controller checks for the existence of the cookie. See Also: "OAM_ID cookie".
OAMAuthnCookie	11g Webgate	Set by each 11g Webgate that is contacted. Protected by the key known to the respective 11g Webgate and the OAM Server. A valid OAMAuthnCookie is required for a session. Note: If the user accesses applications protected by different 11g Webgates, you will have multiple OAMAuthnCookies. See "OAMAuthnCookie for 11g OAM Webgates".
ObSSOCookie	10g Webgate	A domain-based cookie for 10g Webgates is set only when a 10g Webgate is contacted. Protected with keys known to the OAM Server only. One global shared secret key for all Webgates. Note: This cookie enables backward compatibility and inter-operability between Access Manager 11g and older agents. See "ObSSOCookie for 10g Webgates"
OAM_REQ	OAM Server Embedded Credential Collector	A transient cookie that is set or cleared by the OAM Server if the Authentication request context cookie is enabled. Protected with keys known to the OAM Server only. Note: This cookie is configured as a high availability option to store the state about user's original request to a protected resource while his credentials are collected and authentication performed. See "OAM_REQ Cookie".
OAMRequestContext	11g Webgate	A transient cookie that is set or cleared by the 11g Webgate. Protected by the key known to the respective 11g Webgate and the OAM Server. Note: This cookie is configured as a high availability option to store the state about user's original request to a protected resource while his credentials are collected and authentication performed.
DCCCtxCookie	Detached Credential Collector	For detached credential collector (DCC)--similar to OAM_REQ created by embedded credential collector (ECC). See "DCCCtxCookie"
OHS-host-port	Oracle HTTP Server	Set only when OSSO Agents (mod_osso) are contacted on Oracle HTTP Server (OHS). Protected with the key known to the respective mod_osso agent and the OAM Server. Note: This cookie enables backward compatibility and inter-operability between Access Manager 11g and older agents. See "mod_osso Cookies".
GITO cookie	OAM Server	Provides backward compatibility and inter-operability between OSSO 10g and Access Manager 11g. The cookie is created by the OAM Server and accessed or modified by the OAM Server or mod_osso agent. See "mod_osso Cookies".
OpenSSO cookie	OpenSSO Proxy	See "OpenSSO Cookie (iPlanetDirectoryPro)".

For details about configuring authentication and authorization policies, see Chapter 17, "Managing Policies to Protect Resources and Enable SSO".

15.6.2 About Single Sign-On Server and Agent Cookies

• OAM_ID cookie

• OAMAuthnCookie for 11g OAM Webgates

• ObSSOCookie for 10g Webgates

• OAM_REQ Cookie

• DCCCtxCookie

• mod_osso Cookies

• OpenSSO Cookie (iPlanetDirectoryPro)

15.6.2.1 OAM_ID cookie

This cookie is scoped to the OAM Server. OAM_ID is generated by the OAM Server when the user is challenged for credentials, and submitted to the server on every redirect to the server.

OAM_ID is protected by keys known to the OAM Server only.

When a user attempts to access a protected application, the request comes to the SSO Engine and the controller checks for the existence of the cookie:

• If the cookie does not exist, user authentication begins. After successful authentication, the user context and token are set by the SSO Engine. The cookie is set with the global user ID (GUID), creation time, and idle timeout details. Information in the cookie is encrypted with the SSO Server key and can be decrypted only by the SSO Engine.

• If the cookie exists, then the cookie is decrypted and the sign in flow completes with the authenticated user.

15.6.2.2 OAMAuthnCookie for 11g OAM Webgates

There is one OAMAuthnCookie_<host:port>_<random number> set by each 11g Webgate using the authentication token received from the OAM Server after successful authentication. A valid OAMAuthnCookie is required for a session.

SSL Connections: Administrators can ensure the ObSSOCookie is only sent over an SSL connection and prevents the cookie from being sent back to a non-secure Web server by configuring SSL and then specifying Simple or Cert mode for Agents and Servers. For details, see "About Communication Between OAM Servers and Webgates".

Cookie Expiration: For 11g Webgate and OAMAuthnCookie, expiration is controlled by the "tokenValidityPeriod" parameter, which controls the valid token (or cookie) time.

This key is known to both the 11g Webgate and SSO Engine and is used for encrypting OAMAuthnCookie. The SSO engine key (only known to the SSO Engine) is used for encrypting the OAM_ID OAM Server cookie.

Similar to ObSSOCookie for 10g Webgates

15.6.2.3 ObSSOCookie for 10g Webgates

Access Manager 11g sets a key-based cookie ObSSOCookie for each user or application that accesses a resource protected by a 10g Webgate. The key is set up during agent registration and is known to both the agent and SSO Engine (shared between them). This key is different from the OAM Server (or SSO Engine) key.

Removing the ObSSOcookie causes the 10g Webgate to log the user out and requires the user to re-authenticate the next time he or she requests a resource that is protected by the Access System.

The Webgate sends the ObSSOCookie to the user's browser upon successful authentication. This cookie can then act as an authentication mechanism for other protected resources that require the same or a lower level of authentication. When the user requests access to a browser or another resource, the request flows to the OAM Server. The user is logged in, and the ObSSOCookie is set. The OAM Server generates a session token with a URL that contains the ObSSOCookie. Single sign-on works when the cookie is used for subsequent authorizations in lieu of prompting the user to supply authorization credentials.

When the cookie is generated, part of the cookie is used as an encrypted session token. The single sign-on cookie does not contain user credentials such as user name and password.

SSL Connections: Administrators can ensure the ObSSOCookie is only sent over an SSL connection and prevents the cookie from being sent back to a non-secure Web server by configuring SSL and then specifying Simple or Cert mode for Agents and Servers. For details, see "About Communication Between OAM Servers and Webgates".

Cookie Expiration: Administrators can specify the desired Cookie Session Time in the OAM Agent registration. For more information, see "Registering an OAM Agent Using the Console".

15.6.2.4 OAM_REQ Cookie

A transient cookie that is set or cleared by the OAM Server if the Authentication request context cookie is enabled. Protected with keys known to the OAM Server only.

This cookie is configured as a high availability option to store the state about user's original request to a protected resource while his credentials are collected and authentication performed.

In high availability configurations, the Request Cache type must be changed from BASIC to COOKIE using Infrastructure Security custom WLST commands.

Note:

You must invoke the WLST script from the Oracle Common home. See "Using Custom WLST Commands" in the Oracle Fusion Middleware Administrator's Guide.

See Also:

• Oracle Fusion Middleware WebLogic Scripting Tool Command Reference

• Table 15-8, "SSO Cookies"

15.6.2.5 DCCCtxCookie

This comes into play only with the Detached Credential Collector (DCC).

The DCCCtxCookie is used by DCC to save various context information required during authentication. It includes information necessary to reconstruct the original request upon completion of authentication, to maintain server affinity, and to perform iterative multi-step authentication.

By default, DCCCtxCookie is set when the DCC is first redirected away to collect credentials based on the authentication scheme (when the browser is first redirected to the login form with a form-based authentication scheme).

With the DCC, once authenticated the OAM server issues a DCC master session token to the DCC in the authenticate response. DCC then sets a host- based DCC cookie using the token and:

• If DCC cookie Presented During Authentication: DCC decrypts the token using a DCC key, and performs partial token validation locally (integrity check, token validity period check). If it passes, DCC performs complete token validation for timeout aspects over the OAP channel against the OAM Server.

• If no DCC Cookie: This indicates a first time authentication which initiates credential collection, performs sanity and syntactic checks on the credential and submits to OAM Server for validation.

See Also:

"Configuring 11g Webgate and Authentication Policy for DCC"

15.6.2.6 mod_osso Cookies

The mod_osso module is the Oracle HTTP Server module that provides authentication to OracleAS applications. This module resides on the Oracle HTTP Server that enables applications protected by OracleAS Single Sign-On to accept HTTP headers in lieu of a user name and password once the user has logged into the OracleAS Single Sign-On server. The values for these headers are stored in a mod_osso cookie.

Located on the application server, mod_osso simplifies the authentication process by serving as the sole application to the single sign-on server. In this way, mod_osso renders authentication transparent to OracleAS applications. The Administrator for these applications is spared the burden of integrating them with an SDK. After authenticating a user, mod_osso transmits the simple header values that applications may use to authorize the user.

GITO Cookie

Needed in special cases to support timeout when multiple types of agents (mod_osso and Webgate) are working with Access Manager 11g. Server side session managers can check the validity of the cookie for expiry and timeout during session validation. Global logout is required for OSSO Agents (mod_osso) to ensure that logging out of a session on any entity propagates the logout to all entities.

When a user is authenticated by OSSO 10g, the OSSO Server sets GITO cookie. Once the partner cookie (OHS cookie) is set, OHS does not route the request to the server. Instead, on every access, OHS decrypts the GITO cookie and updates the last activity timestamp. During request processing, if any partner detects that current time has surpassed GITO timeout (last activity time + GITO timeout), the request is sent to OSSO 10g in forced authentication mode. When a request reaches OSSO server in forced authentication mode, server chooses to ignore SSO_ID cookie and challenges user for credentials, considering it as a fresh request. After successful authentication, SSO_ID and GITO cookie are updated.

This is enabled (using the editGITOValues WLST command), as described in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

OssoSecureCookies Directive

Add the OssoSecureCookies directive to set the Secure flag on all cookies. This tells the browser to only transmit those cookies on connections secured by HTTPS. An example of this directive in a mod_osso configuration (mod_osso.conf), is as follows:

<IfModule mod_osso.c>
OssoIpCheck off
OssoIdleTimeout off
OssoSecureCookies on
OssoConfigFile osso/osso.conf
<Location /j2ee/webapp>
require valid-user
AuthType Basic
</Location>
</IfModule>

For more information, see Oracle Application Server Single Sign-On Administrator's Guide.

15.6.2.7 OpenSSO Cookie (iPlanetDirectoryPro)

The agent finds this cookie after the OpenSSO Proxy triggers session validation. The default name of the OpenSSO cookie is:

iPlanetDirectoryPro

After the OpenSSO agent is authenticated and logged in, the agent verifies whether the user has an OpenSSO cookie. If not, the user authentication request is initiated from the OpenSSO Agent. During SSO User Login and Authentication flow OpenSSO cookie is created, which contains the OpenSSO session identifier, and this cookie is set in the user's browser.

During End User Session Validation, OpenSSO agent intercepts the request to the protected application and finds an OpenSSO cookie.

During User Single Logout, the OpenSSO Proxy receives a User logout request and forwards the user to the OAM Logout URL OpenSSO Proxy decrypts the OpenSSO cookie, fetches the OpenSSO session identifier and, from that, fetches the OAM session ID. OpenSSO proxy sends the logout request to controller through the OpenSSO logout event with the OAM session ID.

• SSO User Login and Authentication flow

• End User Session Validation flow

• User Single Logout flow

15.7 Introduction to Configuration Tasks for Single Sign-On

The following overview outlines the tasks that Administrators must perform to configure single sign-on with Access Manager 11g,. For each task, a link to additional information is included.

Task overview: Configuring single sign-on

1. Review all topics in this chapter to get familiar with the Access Manager 11g SSO policy model.

2. Configure a single sign-on logout URL for each application you want to protect, using documentation for your specific application.

3. Install and register an Agent on each Web server that is hosting an application to protect using either method. See:

   • Chapter 12, "Introduction to Agents and Registration"

   • Chapter 13, "Registering and Managing OAM 11g Agents"

4. Proceed to manage resource types, host identifiers, authentication schemes, and modules:

   • Chapter 16, "Managing Authentication and Shared Policy Components"

5. Locate an existing Application Domain (or start a fresh one) and add resources and policies, as described in:

   • Chapter 17, "Managing Policies to Protect Resources and Enable SSO"