Understanding Single Sign-On with Access Manager

21.1 Access Manager Single Sign-On Components

Login is the action a user takes to authenticate and gain access to a protected application. Single sign-on (SSO) is the 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 several SSO architectures (including Identity Federation for Partner Networks, and Service Oriented Architecture) and provides SSO through a common SSO Engine for consistent service across multiple protocols. The Oracle Identity Management Infrastructure stores user identities in the identity store referenced in the policy.

Note:

Contextual data is the information that is presented to or collected by Access Manager at various stages of user interaction. These stages include authentication, authorization, enterprise SSO, 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 21-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 21-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: Understanding 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 Registering and Managing OAM Agents. See Also: Managing Policies to Protect Resources and Enable SSO.
Policy Enforcement Agents	OAM Agents (Webgate or Access Client) See Also: 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 22-4
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: Maintaining Access Manager Sessions and Configuring Centralized Logout for Sessions Involving OAM 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 OAM Proxy Metrics and Tuning
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: Managing Policies to Protect Resources and Enable SSO
Policy Store	Database in production environments (otherwise, oam-config.xml). See Also: Managing Data Sources
Cryptographic keys and Key Storage	One key is generated and used per registered OAM Webgate. See Also: Table -1.
Cookies	See: Understanding SSO Cookies.

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

Table 21-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 12c supports cross-network-domain single sign-on out of the box. See Also: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: 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: Multiple WebLogic Server Domain SSO
Reverse-Proxy SSO	This SSO implementation type is supported with a few configuration differences. See Also: Reverse-Proxy SSO
SSO with Mixed Release Agents	Access Manager seamlessly supports registered 12c OAM agents (Webgates and programmatic access clients).

21.1.1 Multiple Network Domain SSO

With Access Manager, this is a standard feature. When OAM 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.

21.1.2 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 12c 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

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

21.1.4 Reverse-Proxy SSO

Reverse-Proxy SSO is a supported configuration.

Following are certain caveats associated with this configuration:

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

21.2 Access Manager Policy Model

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

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

Figure 21-1 Access Manager 12c Policy Model

Description of "Figure 21-1 Access Manager 12c 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
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".

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 12c, 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:

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.

See Also:

Policy Conditions and Rules

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.

21.4 Policy Conditions and Rules

Conditions can be specified only within Authorization and Token Issuance policies. Rules define the Allow or Deny specification that determines the overall effect of the policy.

Unless explicitly stated, information on policy Conditions and Rules applies equally to authorization and Token Issuance policies.

Conditions

Conditions are used in conjunction with Rules that specify Allow or Deny access, based on defined Conditions. Table 21-5 identifies available condition types.

Table 21-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 12c 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 Managing Policies to Protect Resources and Enable SSO.

21.5 Understanding SSO Cookies

SSO cookies are set or cleared during user login.

The following sections provide more information on SSO cookies:

21.5.1 Single Sign-On Cookies During User Login

Single Sign-On Cookies can be set or cleared during user login.

Table 21-6 describes the cookies in detail.

Table 21-6 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	OAMWebgate	Set by each OAM Webgate that is contacted. Protected by the key known to the respective OAM Webgate and the OAM Server. A valid OAMAuthnCookie is required for a session. Note: If the user accesses applications protected by different OAM Webgates, you will have multiple OAMAuthnCookies. See "OAMAuthnCookie for OAM 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	OAM Webgate	Set or cleared by the OAMWebgate and protected by the key known to the respective OAMWebgate and the OAM Server. With Internet Explorer browser: --When RequestContextCookieExpTime is not set, OAMRequestContext is a transient cookie. --When RequestContextCookieExpTime is set, the OAMRequestContext cookie expires by the time set using the "`Expires`" directive. This requires a time sync between the client host and Web server host. With all other (non-IE) browsers, when RequestContextCookieExpTime is not set OAMRequestContext expires in 5 minutes by default or by the time set using the "`Max-Age`" directive. See Also: "OAMRequestContext" Table 15-2
DCCCtxCookie	Detached Credential Collector	For detached credential collector (DCC)--similar to OAM_REQ created by embedded credential collector (ECC). See "DCCCtxCookie"

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

21.5.2 Single Sign-On Server and Agent Cookies

The following sections provide information on the SSO server and agent cookies.

21.5.2.1 OAM_ID cookie

The OAM_ID 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.

21.5.2.2 OAMAuthnCookie for OAM Webgates

There is one OAMAuthnCookie_<host:port>_<random number> set by each OAM 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 OAM Webgate and OAMAuthnCookie, expiration is controlled by the tokenValidityPeriodparameter, which controls the valid token (or cookie) time.

This key is known to both the OAM 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.

21.5.2.3 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 How to Launch the Command-Line Interface in Administering Oracle Fusion Middleware.

See Also:

21.5.2.4 OAMRequestContext

The OAMRequestContext is set or cleared by the 12c Resource WebGate and protected by the key known to the respective 12c WebGate and the OAM Server.

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

With Internet Explorer browser:
- When RequestContextCookieExpTime is not set, OAMRequestContext is a transient cookie.
- When RequestContextCookieExpTime is set, the OAMRequestContext cookie expires by the time set using the "Expires" directive. This requires a time sync between the client host and Web server host.
With all other (non-IE) browsers, when RequestContextCookieExpTime is not set OAMRequestContext expires in 5 minutes by default or by the time set using the "Max-Age" directive.

See Also:

RequestContextCookieExpTime in Table 15-2

21.5.2.5 DCCCtxCookie

The DCCCtxCookie 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.

21.5.2.6 DCCCtxCookie_COUNT

DCCCtxCookie_COUNT cookie maintains the number of cookies generated after splitting the DCCCtxCookie. While the count is determined by the DCCCtxCookie_COUNT cookie, the configuration parameter, MaxSplittedCookieSize fixes the size of each DCCCtxCookie cookie. By default, the size is set to 4 KB.

This feature enables the Webgate to handle large DCCCtxCookie cookies. When the size of the DCCCtxCookie exceeds 4 KB, some browsers do not support and the user authentication fails. Set appropriate value for the Webgate configuration parameter, MaxSplittedCookieSize in order to split the DCCCtxCookie cookie into multiple cookies each of size 4 KB or less. The number of cookies generated after the split of DCCCtxCookie cookie is tracked by DCCCtxCookie_COUNT cookie.

For example, when the requested URL is too long, the size of DCCCtxCookie cookie becomes 6 KB. With the default setting, the DCCCtxCookie splits into two cookies as follows:

DCCCtxCookie_HOST:PORT_1 (size: 4 KB)

DCCCtxCookie_HOST:PORT_2 (size: 2 KB)

You may encounter a ‘bad request’ error while handling a long URL. To avoid this error, edit httpd.conf file and add LimitRequestFieldSize parameter. The default value for LimitRequestFieldSize is 8 KB.

21.5.3 Support for SameSite=None Attribute in OAM Cookies

OAM adds SameSite=None attribute to all the cookies set by WebGate and OAM Server.

Support for SameSite=None Attribute in OAM Cookies

OAM adds SameSite=None attribute to all the cookies set by WebGate and OAM Server.

Note:

You must also download and upgrade to the latest WebGate Patch for this feature to work. For details, see the note Support for SameSite Attribute in Webgate (Doc ID 2687940.1) at https://support.oracle.com.
See also the note Oracle Access Manager (OAM): Impact Of SameSite Attribute Semantics (Doc ID 2634852.1) at https://support.oracle.com.

Optional Configurations on OAM Server

If SSL/TLS is terminated on Load Balancer (LBR) and OAM server is not running in SSL/TLS mode, set the following system property in setDomainEnv.sh: -Doam.samesite.flag.value=None;secure
Alternatively, you can propagate SSL/TLS context from the LBR or Web Tier to OAM Server. For details, see Doc ID 1569732.1 at https://support.oracle.com.
To disable the inclusion of SameSite=None by OAM Server, set the following system property in setDomainEnv.sh: -Doam.samesite.flag.enable=false
To set SameSite=None for non-SSL/TLS HTTP connections, set the following system property in setDomainEnv.sh: -Doam.samesite.flag.enableNoneWithoutSecure=true

Example - To add the system properties to setDomainEnv.sh:

Stop all the Administration and Managed Servers.

Edit the $OAM_DOMAIN_HOME/bin/setDomainEnv.sh, and add the properties as shown:

EXTRA_JAVA_PROPERTIES="-Doam.samesite.flag.enable=false ${EXTRA_JAVA_PROPERTIES}"
export EXTRA_JAVA_PROPERTIES

Start the Administration and Managed Servers.

Optional Configurations for WebGate

If SSL/TLS is terminated on LBR and OAM Webgate WebServer is not running in SSL/TLS mode, set the ProxySSLHeaderVar in the User Defined Parameters configuration to ensure that WebGate treats the requests as SSL/TLS. For details, see User-Defined WebGate Parameters.
To disable inclusion of SameSite=None by OAM WebGate, set SameSite=disabled in the User Defined Parameters configuration on the console. This is a per-agent configuration.
To set SameSite=None for non-SSL HTTP connections, set EnableSameSiteNoneWithoutSecure=true in the User Defined Parameters configuration on the console. This is a per-agent configuration.

Note:

In deployments using mixed SSL/TLS and non-SSL/TLS components: For non-SSL/TLS access, OAM Server and Webgate do not set SameSite=None on cookies. Some browsers (for example, Google Chrome) do not allow SameSite=None setting on non-secure (non-SSL/TLS access) cookies, and therefore, may not set cookies if a mismatch is found.

Therefore, it is recommended that such mixed SSL/TLS and non-SSL/TLS deployments are moved to SSL/TLS Only deployments to strengthen the overall security.

21.6 Configuring Single Sign-On with Access Manager

Administrators can perform configuration of single sign-on with Access Manager, manage resource types, host identifiers, and add resources and policies.

For each task, a link to additional information is included.

Review all topics in this chapter to get familiar with the Access Manager SSO policy model.
Configure a single sign-on logout URL for each application you want to protect, using documentation for your specific application.
Install and register an Agent on each Web server that is hosting an application to protect using either method. See:
- Introduction to Agents and Registration
- Registering and Managing OAM Agents
Proceed to manage resource types, host identifiers, authentication schemes, and modules:
- Managing Authentication and Shared Policy Components
Locate an existing Application Domain (or start a fresh one) and add resources and policies, as described in:
- Managing Policies to Protect Resources and Enable SSO