16 Managing Authentication and Shared Policy Components

This chapter describes how Administrators can manage shared policy components in the following topics:

• Prerequisites

• Introduction to Managing Authentication and Shared Policy Components

• Managing Resource Types

• Managing Host Identifiers

• Understanding Authentication Methods and Credential Collectors

• Managing Native Authentication Modules

• Orchestrating Multi-Step Authentication with Plug-in Based Modules

• Deploying and Managing Individual Plug-ins for Authentication

• Managing Authentication Schemes

• Configuring Challenge Parameters for Encrypted Cookies

• Understanding Password Policy

• Managing Global Password Policy

• Configuring Password Policy Authentication

• Configuring 11g Webgate and Authentication Policy for DCC

• Completing Password Policy Configuration

• Configuring Authentication Post Data Handling

• Configuring Long URL Handling During Authentication

16.1 Prerequisites

The Oracle Access Management Console and at least one OAM Server must be installed and running within a WebLogic Server domain. Access Manager must be running with at least two registered Agents.

Oracle recommends that you review information in Chapter 15, "Introduction to Single Sign-On with Access Manager" before performing activities in this chapter.

16.2 Introduction to Managing Authentication and Shared Policy Components

This section introduces the tasks that must be performed to configure shared policy components required for use in Access Manager authentication policies that protect resources and enable single sign-on.

See Also:

Chapter 15, "Introduction to Single Sign-On with Access Manager"

Task overview: Configuring shared policy components

1. Confirm that the desired resource type is defined, as described in this chapter:

   • Managing Resource Types

2. Confirm that a host identifier definition named for the agent was created during agent registration, (or create one yourself), as described in:

   • Managing Host Identifiers

3. Gain comprehension about credential collection with Access Manager:

   • Understanding Authentication Methods and Credential Collectors

4. Learn about and use the authentication plug-ins that enable multi-step authentication:

   • Orchestrating Multi-Step Authentication with Plug-in Based Modules

   • Deploying and Managing Individual Plug-ins for Authentication

5. Create and manage authentication schemes that you can add to authentication policies, as described in:

   • Managing Authentication Schemes

   • Configuring Challenge Parameters for Encrypted Cookies

6. Set up your own global password policy for either the default embedded or optional detached credential collector (unless specified, tasks apply to both ECC and DCC, with minor changes noted in the discussion):

   • Understanding Password Policy

   • Managing Global Password Policy

   • Configuring Password Policy Authentication

   • DCC: Configuring 11g Webgate and Authentication Policy for DCC

   • Completing Password Policy Configuration

7. Proceed to Chapter 17 to set up authentication policies.

16.3 Managing Resource Types

This section includes the following topics:

• About Resource Types and Their Use

• About the Resource Type Page

• Searching for a Specific Resource Type

• Creating a Custom Resource Type

16.3.1 About Resource Types and Their Use

When adding a resource to an Application Domain, Administrators must choose from a list of defined Resource Types. Oracle-provided resource types include:

• HTTP

• wl_authen

• TokenServiceRP

Administrators can define additional resource types, and define operations on both Oracle-provided and custom resource types. A particular resource can be defined to use a subset of the declared operations, or all of them (which includes any new operators defined on the resource's type subsequently.Administrators cannot remove custom resource types or operations for which resources have been created. Oracle-provided resource types and operations are marked as read-only within the policy store and cannot be removed.

Note:

Changes to the operation list of a resource type is not allowed if a resource of that type exists.

Table 16-1 compares resource types and operations.

Table 16-1 Comparison: Resource Types for Access Manager versus 10g

Access Manager 11g	Oracle Access Manager 10g
HTTP: The default resource type used with HTTP and HTTPS protocols. When adding an HTTP type resource to an Application Domain, Administrators must choose from a list of existing host identifiers and add the resource URL. This resource type is read-only. Default operations associated with the HTTP resource type need not be defined by an Administrator. Instead, policies developed and applied to the resource apply to all operations: Operations: Oracle-provided resource types are read-only; associated operations are pre-defined. Policies developed and applied to HTTP type resources apply to all operations. Get Post Put Head Delete Trace Options Connect Other See Also: "About the Resource Type Page".	HTTP: The HTTP resource type is read-only. Operations: Oracle-provided resource types are read-only; associated operations are pre-defined. Policies developed and applied to the resource apply to all operations. Get Post Put Head Delete Trace Options Connect Other
wl_authen: Resources for representing WebLogic Authentication schemes is also read-only (default operations cannot be modified or deleted.) This non-HTTP resource type is available to use with resources deployed in a WebLogic container in a domain that does not include Access Manager. The protected resource is accessed through its URL on the Oracle WebLogic Server. Type wl_authen resources, require a custom Access Client.	N/A
TokenServiceRP: Resources for representing Token Service Relying Party. The Operation for this resource type is Issue.	N/A
Custom Resource Types: Have no associated host identifier. A custom "EJB" resource type can be created on demand for use in SSO integrations.	EJB: A custom resource type used in SSO integrations with WebLogic and WebSphere for authenticating the user. During authentication, the user's groups were fetched and populated in the Subject Principal as roles. Subsequent authorization was executed inside the application server based on user roles. No authorization calls were made using resource operations.
Non-HTTP resource types have no associated host identifier. When adding non-HTTP resources to an Application Domain, Administrators must enter the Type name into the Resource URL field as a pointer. The name cannot match any host Identifier (and vice versa). This is not a relative HTTP URL.

16.3.2 About the Resource Type Page

In the Oracle Access Management Console, resource types are organized with other Components under the Policy Configuration tab. The navigation tree shows Oracle-provided resource types: HTTP, wl_authen, and TokenServiceRP.

Note:

Pre-defined resource types cannot be deleted. Pre-defined operations are shown with a lock icon and cannot be deleted. Additional operations can be created, edited, or deleted as needed.

The HTTP resource type, shown in Figure 16-1, is used for Web applications protected by Access Manager and accessed using internet protocols (HTTP or HTTPS).

Figure 16-1 Default HTTP Resource Type Definition

Description of "Figure 16-1 Default HTTP Resource Type Definition"

The wl_authen resource type is shown in Figure 16-2. It is used for Fusion Middleware applications that use one of the following Access Manager Identity Assertion Provider configurations described in the Oracle Fusion Middleware Application Security Guide:

• Identity Asserter

• Identity Asserter with Oracle Web Services Manager

• Authenticator function

Figure 16-2 Default Resource Type wl_authen

The TokenServiceRP resource type represents the Token Service Relying Party, as shown in Figure 16-3. The operation for this resource type is Issue. For more information, see "Managing TokenServiceRP Type Resources".

Figure 16-3 Default Resource Type TokenServiceRP Resource Type

Description of "Figure 16-3 Default Resource Type TokenServiceRP Resource Type"

Table 16-2 describes the elements in each resource type definition.

Table 16-2 Resource Type Definition

Element	Description
Name	Required. A unique name of up to 30 alpha or numeric characters. Note: A non-HTTP Resource Type name cannot match a Host Identifier (and vice versa).
Description	Optional. Use this field to describe the purpose of this resource type using up to 200 alpha or numeric characters. For example: Resources representing WebLogic Authentication schemes.
Operations	Optional. Policies that govern a particular resource apply to all specified operations defined for the resource. Add (or remove) operations for this resource type as a string and the operations will be available when you define a resource of this type within an Application Domain. There is no limit to the number of operations that can be added to the resource type. Get Post Put Head Issue (TokenServiceRP) Login (wl_authen) Delete Trace Options Connect Other (available with Oracle Access Manager 10 is not supported in 11g). Remote Registration: During automatic policy creation, specified operations are supported. During automatic policy creation with no operations specified, then All operations defined for that type are supported. Migration: During an upgrade to Access Manager 11.1.2 (from 10g or from 11.1.1.3 or from 11.1.1.5), resource definitions and HTTP default operations are handled automatically. However, you must create any custom resource types to replace 10g-provided EJB custom resource types which are no longer provided by Oracle. See See Also: "About Resource Types and Their Use" and "About Defining Resources in an Application Domain".

Following topics describe how to create, modify, and delete a resource type.

16.3.3 Searching for a Specific Resource Type

Users with valid Administrator credentials can use the following procedure to locate a defined resource type.

See Also:

"Conducting Searches Using the Console"

To search for a resource type

1. Activate the Oracle Access Management Console Policy Configuration tab, then click the Search tab.

2. From the search type list, choose Resource Type, enter the name of the Resource Type you want to find (with or without a wild card (*)), and click Search. For example:

   h*
   

   Alternatively: Go to the desired Application Domain, open the Resources node to display controls for that domain, choose a Resource Type from the list, and click Search.

3. Click the Search Results tab to display the results table, and then:

   • Edit or View: Click the Edit button in the tool bar to display the configuration page.

   • Delete: Click the Delete button in the tool bar to remove the instance; confirm removal in the Confirmation window.

   • Detach: Click Detach in the tool bar to expand the table to a full page.

   • Reorder Columns: Select a View menu item to alter the appearance of the results table.

4. Click the Browse tab to return to the navigation tree when you finish with the Search results.

16.3.4 Creating a Custom Resource Type

Users with valid Administrator credentials can use the following procedure to create a defined resource type. For instance, you can define a custom resource type that applies to as few as one or two (or more) operations. Any defined custom resource type is listed with default resource types when adding resources to an authentication or authorization policy.

See Also:

• "About Resource Types and Their Use"

• "Defining Resources in an Application Domain"

To create a custom resource type

1. Activate the Oracle Access Management Console Policy Configuration tab.

2. Under Shared Components, click the Resource Type node and then click the Add + button.

3. Enter the following information:

   • Name: A unique name that identifies this resource type.

   • Description: Optional.

   • Operations: Click + in the Operations table, type the operation name into the field provided. Repeat as needed to define all operations for this resource type.

   • Reconfigure Table: Select a View menu item to alter the appearance of the results table.

4. Click Apply to submit this custom resource definition.

5. Add this resource definition to an Application Domain as described in "Adding and Managing Resource Definitions to be Added to Policies".

16.4 Managing Host Identifiers

This section describes host identifiers and their use as well as how to create, modify, or remove a host identifier. Topics here include:

• About Host Identifiers

• About Virtual Web Hosting

• About the Host Identifier Page

• Creating a Host Identifier

• Searching for a Host Identifier Definition

• Viewing or Editing a Host Identifier Definition

• Deleting a Host Identifier Definition

16.4.1 About Host Identifiers

Access Manager policies protect resources on computer hosts. Within Access Manager, the computer host is specified independently using a host identifier.

Table 16-3 illustrates the different host names under which a Web server might be accessible to employees. Creating a single Host Identifier using all of these names allows you to define a single set of policies to appropriately protect the application, regardless of how the user accesses it.

Table 16-3 Host Identifiers Examples

Sample Host Identifier	Description
hrportal.intranet.company.com	A friendly name employees can remember. This is a load-balanced proxy, and requests to this could actually utilize one of several servers hosting the HR application.
hr-sf-02.intranet.company.com	A single machine hosting the application, which can be accessed directly.
hrportal.company.com	The same application is also accessible externally to the corporate firewall, primarily for use by ex-employees to check benefits, 401k info, and so on. This is also a load-balanced reverse proxy.

Based on a defined host identifier, Administrators can add specific resources to an Application Domain and apply policies to protect those resources.

Registered Agents protect all requests that match the addressing methods defined for the host identifier used in a policy. A request sent to any address on the list is mapped to the official host name and Access Manager can apply the policies that protect the resource and OAM can apply the policies that protect the resource.

A host identifier is automatically created when an Agent (and application) are registered using either the Oracle Access Management Console or the remote registration tool. Administrators can manually add a host identifier if an application and resources exist on a host that does not have a mapped host identifier. Also, Oracle Access Management Administrators can modify an existing host identifier to add in the new host name variations. For instance, adding another proxy Web server with a different host name requires a new host name variation.

For more information, see:

• Host Identifier Usage

• Host Identifier Guidelines

• Host Identifier Variations

16.4.1.1 Host Identifier Usage

At design time, the host identifier can be used while defining which resources belong to a specific Application Domain. Resources are scoped using their host identifier (HTTP) or type (non-HTTP). This combination uniquely identifies them across Access Manager.

Note:

Each resource should be unique across all Application Domains; each resource and host identifier combination must be unique across all Application Domains.

Runtime Usage

At run time, Web server host information in the access query from an OAM Agent is mapped to a host identifier and associated with the resource that is being accessed by a user. The OAM Agent obtains the Web server host information in one of two ways:

• If the Preferred Host parameter is configured for virtual Web hosting support (see"About Virtual Web Hosting"), Web server host information for the given request is obtained from the Web server.

• If the Preferred Host parameter directly specifies the Web server host information, it is always used irrespective of the Web server's own host information.

This allows for the Resources to be specified in terms of logical host names in their Host Identifiers, instead of the host names matching the present deployment of the Web server.

For instance, a user accessing aseng-wiki, would enter:

http://example-wiki.uk.example.com/wikiexample

Here, wikiexample is the resource URL and example-wiki.uk.example.com is the host. Matching this host and port (port is 80) provides the host identifier.

Preferred Host

Web server host information is generally acquired by setting the Preferred Host string of the OAM Agent. If the Agent is actively protecting multiple virtual hosts, this string can be set to server_name to ensure that the actual request hostname is correctly picked up from the Web server's request object. For more information, see "About Virtual Web Hosting"

Authenticating Hosts and Challenge Redirect in Authentication Schemes

When a user attempts to access a protected resource URL, she is redirected to the server specified in the Challenge Redirect field of the authentication scheme. If the authentication challenge is to be processed by another host, the name of that host must be defined to be available in the Host Identifiers list. For example, if a user is redirected to an SSL-enabled server for authentication, that server must be defined as a host identifier.

Note:

If you enter a host name in the Challenge Redirect field of an authentication scheme, it must be defined as a Host Identifier.

16.4.1.2 Host Identifier Guidelines

Each host identifier can be defined to represent one or more Web server hosts. Following are several important guidelines for host identifiers:

• Each host name must be unique.

• Each host name:port pair must be unique.

• Each host name:port pair must belong to only one host identifier.

• Each host name:port pair must match the end user's entry exactly.

• A Host Identifier name cannot match a non-HTTP Resource Type name (and vice versa).

• Each resource and host identifier combination must be unique across all Application Domains.

For more information, see "Host Identifier Variations".

16.4.1.3 Host Identifier Variations

Host identifiers are used to simplify the identification of a Web server host by defining all possible hostname variations. Host identifiers consist of a list of all URL addressing methods. A host identifier must be configured for each Web site or virtual Web site that you want to protect with Access Manager.

You can identify Web server hosts to Access Manager in various ways, for example, by providing a computer name or an IP address. The following are examples of how the same host can be addressed:

• example.com

• example.com:80

• www.example.com

• www.example.com:80

• 216.200.159.58

• 216.200.159.58:80

16.4.2 About Virtual Web Hosting

You can install a Webgate on a Web server that contains multiple Web site and domain names. The Webgate must reside in a location that enables it to protect all of the Web sites on that server.

Note:

The information here is the same for both 11g and 10g Webgates.

The virtual Web hosting feature of many Web servers enables you to support multiple domain names and IP addresses that each resolve to their unique subdirectories on a single virtual server. For example, you can host abc.com and def.com on the same virtual server, each with its own domain name and unique site content. You can have name-based or IP-based virtual hosting.

A virtual host referees the situation where the same host has 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).

Consider a case where you have two virtual hosts configured on an OHS Server acting as reverse proxy to OAM Server, as follows:

• One virtual host is configured in two-way SSL mode

• One virtual host configured in non-SSL mode

Suppose there are two resources protected with different authentication schemes and Application Domains:

• /resource1 is protected by a X509Scheme with a Challenge URL (to define the credential collection URL) of https://sslvhost:port/

  When the user accesses /resource1 he is redirected to the OHS Server on the SSL port for authentication and is asked for the X.509 Certificate.

• /resource2 is protected by a LDAPScheme on the second virtual host with a Challenge Redirect of http://host:port/

  When user accesses /resource2 he is redirected to second virtual host which is in non-SSL mode (or in one way SSL mode if required). The Login form for LDAP authentication is displayed.

Note:

Your deployment can support X.509 and Form authentication with 10g mod_osso. However, mod_osso can be configured for only one SSO Server. In this case, the Agent redirects to Access Manager on the non-SSL virtual host. The credential collector checks the Authentication Scheme's Challenge URL parameter for the resource and redirects back to the HTTPS virtual host for X509 authentication.

16.4.2.1 Placing a Webgate Behind a Reverse Proxy

You can use 10g Webgates with reverse proxies for Access Manager. This topic discusses benefits and pitfalls of this strategy.

Benefits:

• All Web content can be protected from a single logical component as long as all requests go through the proxy.

  This is true even for platforms that are not supported by Access Manager. If you have different types of Web servers (for example, iPlanet, Apache, and so on) on different platforms (for example, Windows XP, Linux, and so on), all content on these servers can be protected. A reverse proxy can be a workaround for unsupported Web servers, eliminating the need to write custom Access Clients for unsupported Web servers and on platforms that do not have Webgate support, for example, MacOS.

• A reverse proxy offers architecture flexibility.

  Reverse proxies can allow deployments to expose an application that is available on the intranet to the extranet. Or applications that are available on the extranet can be exposed to the intranet. This can be done without any changes to the application that is already deployed.

• You only need to install a separate Webgate on the reverse proxy, rather than on every Web server.

  This allows for a single management point and can help with manageability of the system. You can manage the security of all of the Web servers through the reverse proxy without establishing a footprint on the other Web Servers.

Pitfalls: The main pitfall of using a proxy is the extra work involved in setup. If you deploy the Webgate on a Web server that is behind a reverse proxy, the following are configuration requirements:

• Ensure that any Web server that uses the reverse proxy for authentication only accepts requests from the reverse proxies.

  This will also require that Webgates deployed on this Web server be configured to not enforce IP validation for requests from the reverse proxy server that front-ends the Webgate. This is done by configuring the known IP addresses of the reverse proxy server or servers in the IP Validation list. Note that while you can achieve the same effect by turning IP validation off for the Webgate, this is not a recommended approach due to security risks.Ensuring that the Web server only accepts requests from reverse proxies is typically done by adding an ACL statement in the server. This prevents users from bypassing the reverse proxy and directly accessing restricted content.

• Update the virtual hosts that are configured in the Policy Manager so that the Access System intercepts requests that are sent to the reverse proxy.

• Prevent people from circumventing the proxy by entering URLs that point directly to the back-end system.

  You can prevent this problem through the use of Web Server Access Control Lists or firewall filters.

• Since all user requests are processed by the proxy, you must deploy enough proxy servers to enable the system to handle the load.

• Redirect all existing URLs to the host name and port number of the reverse proxy server.

  This often requires configuring the reverse proxy to perform content inspection and rewriting to prevent any absolute HTML links, for instance, to prevent broken link. This is achievable with most reverse proxies, and this is something you can configure independently of the Access System,.

• It is a best practice that URL links exposed to the front-ended applications rely on only relative URLs (../../sub-path/resource) rather than absolute URLs (http://example.com:[port]/path/resource).

  Absolute URLs can break links on the end user's browser when deployed behind a reverse proxy.

16.4.2.2 Configuring Virtual Hosting for Non-Apache Web Servers

Ensure that the Virtual Host box is checked on the 10g Webgate registration page.

On most Web servers, other than Apache-based servers, you must set the Preferred Host value to HOST_HTTP_HEADER. This ensures that, when user's browser sends a request, the Webgate sets the value of the Preferred Host to the host value in the request. For example, suppose a user enters the string example2 in a URL:

http://example2

On the Web server, if one of the Web sites has a host named example2, the request is served by the matching virtual site.

In the Preferred Host field of the expanded 10g Webgate registration page, enter the following:

HOST_HTTP_HEADER.

IIS Virtual Hosting: From the IIS console, you must configure each virtual Web site to contain the following fields:

• Host Header Name

• IP address

• Port

See Also:

• http://www.simpledns.com/kb.aspx?kbid=1149

• http://support.microsoft.com/kb/q190008/

16.4.2.3 Associating a Webgate for Apache with Virtual Hosts, Directories, or Files

Ensure that the Virtual Host box is checked on the 10g Webgate registration page.

On Apache-based Web servers (Apache, Apache 2, IBM HTTP Server, Oracle HTTP Server, and so on), the Preferred Host value must be set to SERVER_NAME.

Note:

The SERVER_NAME value is not supported for any host other than an Apache-based server. If you set this value for a non-Apache-based server, users will be unable to access any resources that are protected by Webgate on that Web server. Users will, instead, receive an error that the Webgate configuration is incorrect.

The ServerName directive must be explicitly set with 7777 along with the hostName. This is irrespective of the Listen directive is set correctly. The Server sometimes requires this value explicitly to identify itself, most often it can identify itself automatically.

When using an Apache-based reverse proxy for single sign-on, in the Web server configuration file (httpd.config, for example) file you specify the Web sites to run on the Apache server. The settings can be global across all Web sites or local to a Web site. You can restrict the Access Manager loading references in the httpd.config file to be associated with a specified site, with virtual hosts, specific directories or even files.

To associate the Webgate with specific targets, you move the following directives the the http.conf file:

AuthType Oblix
require valid-user

You can put these directives in a block that tells Apache to use Webgate for every request. You can also move the directives to a block that limits when the Webgate is called. The following is an example of putting the LocationMatch directive after a VirtualHost directive:

  DocumentRoot /usr/local/apache/htdocs/myserver    
  ServerName myserver.example.net    
  AuthType Oblix       
  require valid-user    

After you move the LocationMatch block to the VirtualHost directive, the Webgate will only work for that virtual host. You can add the LocationMatch block to as many virtual hosts as you want. The following examples shows how you could protect one virtual server:

ServerAdmin [e-mail]
DocumentRoot "Z:/Apps/Apache/htdocs/MYsrv"
ServerName apps.example.com
    ProxyRequests On
    SSLEngine on
    SSLCACertificateFile Z:/Apps/sslcert_exampleapps_ptcweb32/intermediateca.cer
    SSLCertificateFile Z:/Apps/sslcert_exampleapps_ptcweb32/sslcert_myapps_ptcweb32.cer
    SSLCertificateKeyFile Z:/Apps/sslcert_exampleapps_ptcweb32/sslcert_myapps_ptcweb32.key
    ErrorLog logs/proxysite1_log
    CustomLog logs/proxysite1_log common
    ProxyPass /https://apps.example.com/
    ProxyPassReverse /https://apps.example.com/
    ProxyPass /bkcentral https://apps.example.com/bkcentral
    ProxyPassReverse /bkcentral https://apps.example.com/bkcentral
    ProxyPass /NR https://apps.example.com/NR
    ProxyPassReverse /NR https://apps.example.com/NR
    
      AuthType Oblix
      require valid-user
    
#*** BEGIN Oracle Access Manager Webgate Specific **** 
 
LoadModule obWebgateModule Z:/apps/Oracle/WebComponent/access/oblix/apps/webgate/bin/webgate.dll
WebgateInstalldir Z:/apps/Oracle/WebComponent/access
WebgateMode PEER
 
 SetHandler obwebgateerr
 
SSLMutex sem
SSLRandomSeed startup builtin
SSLSessionCache none
 
SSLLog logs/SSL.log
SSLLogLevel info
# You can later change "info" to "warn" if everything is OK

16.4.3 About the Host Identifier Page

A host identifier is automatically created when an Agent (and application) are registered using either the Oracle Access Management Console or the remote registration tool. In the Application Domain that is registered with the Agent, the host identifier is used automatically.

Administrators can use the console to create and manage host identifiers. Within the Oracle Access Management Console, host identifiers are organized under Shared Components, on the Policy Configuration tab navigation tree. Administrators can manually create a new host identifier definition, modify a definition, delete a definition, or copy an existing definition to use as a template. The name of the copy is based on the original definition name. For example, if you copy a definition named host3, the copy is named copy of host3.

Figure 16-4 illustrates a typical Host Identifier configuration page in the console, where you enter the canonical name for the host, and every other name by which the same host can be addressed by users.

Note:

Each host identifier must be unique. You cannot use the same host name and port in any other host identifier definition.

Figure 16-4 Host Identifier Page

Description of "Figure 16-4 Host Identifier Page"

Table 16-4 describes the host identifier definition.

Table 16-4 Host Identifier Definition

Property	Description
Name	A unique name for this definition. Use only upper- and lower-case alpha characters. No punctuation or special characters are allowed.
Description	The optional description, up to 200 characters, that explains the use of this configuration.
Host Name Variations	Host Name: A list of the various host names or permutations that users might use when accessing the application. See also: "Host Identifier Variations" and "Host Identifier Guidelines". Port: The Web server port used by each host or permutation

16.4.4 Creating a Host Identifier

Users with valid Administrator credentials can use the following procedure to create a host identifier definition manually. This is needed if an application and resources were manually added to a host that has no mapped host identifier. When you choose Auto Create Policies when registering an Agent, this is done automatically.

Note:

If you copy an existing definition to use as a template, you must modify all unique identifiers in the copy.

See Also:

• "About Host Identifiers"

• "About Virtual Web Hosting"

To manually create a Host Identifier

1. From the Oracle Access Management Console Policy Configuration tab, open the Host Identifiers node.

2. Click the Create Host Identifier button in the upper-right corner of the Search Host Identifiers page.

   Alternatively: Open the Host Identifiers node, click the Create (+) button above the Search Results table.

3. On the fresh Host Identifier page, fill in the:

   1. Name

   2. Description

   3. Host Name Variations: Add (or remove) host name and port variations in the Operations list.

      Add: Click the Create (+) button, then enter a new host name and port combination to identify variables that map to the Host Identifier Name.

      Remove: Click a host name, then click the Delete button to remove it.

4. Repeat step 3c as needed to identify all variations of this host that users can access.

5. Click Apply to submit the new definition (or close the page without applying changes).

6. Close the Confirmation window, and confirm the new definition is listed in the navigation tree.

16.4.5 Searching for a Host Identifier Definition

Users with valid Administrator credentials can perform the following task to search for a specific host identifier.

Note:

During Delete, if the Host Identifier is associated with a resource, you are prompted with an alert. Without any association, the Host Identifier is deleted successfully.

See Also:

"Conducting Searches Using the Console"

To find for a host identifier

1. From the Oracle Access Management Console Policy Configuration tab, open the Host Identifiers node.

2. In the Search Host Identifiers page Name field, enter a name (or a partial name with wild card (*)), or leave the Name field blank to show all Host Identifiers. For example:

   my_h*
   

3. Click the Search button to initiate the search and display results in a table, then:

   • View or Edit: Double-click the name in the Search Results table to display the configuration page, then add or edit as usual.

   • Delete: Click the Delete button in the tool bar to remove the selected item in the results table; confirm removal in the Confirmation window.

   • Detach: Click Detach in the tool bar to expand the Search Results table to a full page (or from the View menu, click Detach).

   • Reorder Columns: From the View menu, select reorder Columns and use the arrows provided to reorder the columns.

16.4.6 Viewing or Editing a Host Identifier Definition

Users with valid Administrator credentials can use the following procedure to modify a host identifier definition. This can include adding, changing, or removing individual host identifiers from the definition. For instance, when adding another proxy Web server with a different host name, you might need to modify an existing host identifier definition to add the new host name variation.

Prerequisite: Inventory Application Domains that refer to the host identifier and

Note:

After viewing settings, you can either close the page or modify settings as needed.

See Also:

"About the Host Identifier Page"

To view or modify a Host Identifier

1. Locate the desired host identifier and view it as described in "Searching for a Host Identifier Definition".

2. On the Host Identifier page, modify information as needed (Table 16-4):

   1. Name

   2. Description

   3. Host Name Variations: In the table provided:

      Add (+) Host Name Variations: Click the Add (+) button, then enter a new host name and port combination to identify variables that map to the Host Identifier Name.

      Delete (X) Host Name Variations: Click a host name, then click the Delete button to remove it.

3. Repeat step 3c as needed to add or remove variations.

4. Click Apply to submit the changes (or close the page without applying changes).

5. Dismiss the Confirmation window, and close the page when you finish.

16.4.7 Deleting a Host Identifier Definition

Users with valid Administrator credentials can use the following procedure to delete an entire host identifier definition. A validation error occurs if you attempt to delete the host identifier that is being used in a resource.

Note:

If the Host Identifier is associated with a resource, you are alerted. Without any association, the Host Identifier is deleted.

Prerequisites

Each resource in an Application Domain is associated with a specific host identifier. If you intend to delete a host identifier you must first modify any resource definitions in an Application Domain that uses this host identifier.

See Also:

"Viewing or Editing a Host Identifier Definition" if you want to remove a single host identifier from an existing definition.

To delete a Host Identifier

1. Locate and modify related resource definitions in any application domains that uses this host identifier. See "Searching for a Resource Definition".

2. Locate the desired host identifier as described in "Searching for a Host Identifier Definition".

3. View: Double-click the name in the results table to display the configuration page, and confirm this can be removed.

4. Delete: Click the Delete button in the tool bar to remove the selected item in the results table; confirm removal in the Confirmation window.

16.5 Understanding Authentication Methods and Credential Collectors

With Access Manager, authentication involves redirecting the requester (user) to a centralized component that performs authentication (known as the Credential Collector).

This section provides the following topics:

• About Different Authentication Methods

• Comparing Embedded Credential Collector with Detached Credential Collector

• Authentication Event Logging and Auditing

16.5.1 About Different Authentication Methods

Authentication is the process of proving that a user is who he or she claims to be. 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.

Using Access Manager, a resource or group of resources can be protected by a single authentication process known as an authentication scheme. Authentication schemes rely on pre-defined authentication modules or plug-ins.

This section describes multi-level authentication and other authentication methods supported by Access Manager.

Multi-level Authentication

Access Manager enables Administrators to assign different authentication levels to different authentication schemes, and then choose which scheme protects which application. Every authentication scheme requires a strength level. The lower this number, the less stringent the scheme. A higher level number indicates a more secure authentication mechanism.

SSO capability enables users to access more than one protected resource or application with a single sign in. A user who is authenticated to access resources at level 2, is eligible to access resources protected at levels less than or equal to 2. However, if the user is authenticated to access resources at level 2 and then attempts to access resources protected by level 3, the user is asked to re-authenticate (this is known as step-up authentication).

For more information, see "About Multi-Level and Step-Up Authentication".

Multi-Step Authentication

Multi-step authentication requires a custom authentication module composed of two or more authentication plug-ins that transmit information to the backend authentication scheme several times during the login process. All information collected by the plug-in and saved in the context will be 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.

See "Comparing Simple Form and Multi-Factor (Multi-Step) Authentication".

Windows Native Authentication

Integrated Windows Native Authentication is supported for both OSSO and Webgate protected applications. This form of authentication relies on the Kerberos authentication module. For more information, see Chapter 43, "Configuring Access Manager for Windows Native Authentication".

Other Authentication Types

Authentication features required by Oracle Fusion Middleware applications are supported, including:

• Weak authentication, typically a user name and password, no certificates

• Auto-login with third-party self-service user provisioning

• HTTP header support for user context information. For instance, host identifiers are used to create a host context for the resource. This is useful when adding resources that have the same URL paths on different computers.

If you use different authentication schemes for two WebGates, users can go from a higher authentication scheme to a lower one without re-authentication, but not from a lower level to a higher level.

Note:

During single sign-on, users might pass the authentication tests but might fail authorization tests when attempting to access a second or third resource. Each resource in the domain might have a unique authorization policy.

For details about configuring and using authentication schemes with Access Manager, see "Managing Authentication Schemes".

16.5.2 Comparing Embedded Credential Collector with Detached Credential Collector

Access Manager 11.1.2 supports the embedded credential collector (ECC) by default and also enables you to configure the latest Webgate to use as a detached credential collector (DCC, also known as an Authenticating Webgate).

The DCC is considered more secure than the default embedded credential collector (ECC). The centralized DCC presents the login page, collects user credentials (userID and password, for example), and sends these to the OAM Server using the back channel Oracle Access Protocol (OAP). Additional credentials can be requested using the DCC.

When OAM Server is configured to use the DCC, the ECC and its HTTP endpoints are disabled. The only HTTP communication is to the Oracle Access Management Console hosted by the WebLogic AdminServer in the domain where the OAM Server is deployed. Connectivity to the AdminServer can be controlled at the network level, for example, to disallow administration requests from outside the internal network.

• Allowing both the ECC and DCC to co-exist enables you to use authentication schemes and policies configured for use with either the ECC or the DCC. This enables a fallback mechanism for resources that rely on the ECC, which includes the Oracle Access Management Console.

• Disabling (turning off) the ECC entirely prohibits access to resources that rely on the ECC mechanism, including the Oracle Access Management Console.

While the embedded and detached credential collectors (ECC and DCC, respectively) are essentially the same, compare the two in Table 16-5.

See Also:

"Introduction to Access Manager Credential Collection and Login"

Table 16-5 Comparing the DCC and ECC

	DCC	ECC
Deployment	The Detached Credential Collector remains a logical part of the server and acts as a front channel communication endpoint of the OAM Server. However, the DCC also: Stands alone (detached from the OAM Server and does not require an application server). Supports RSA SecurID passcode verification, get next token, create new pin workflows. Is similar to the earlier 10g Authenticating Webgate with greater flexibility for server scale-out and attack resilience as well as credential collection UI construction, flow, and lifecycle management.	The Embedded Credential Collector is deployed with, and integral to, the OAM Server and part of the protocol binding layer. The ECC supports RSA SecurID passcode verification, get next token, create new pin workflows.
DMZ Deployment	Yes. The main benefit of a deployment using DCC in the DMZ is the termination of the end-user network connections within the public network, and the use of Oracle Access Protocol (Oracle's proprietary application network protocol) over mutually authenticated connections reaching the OAM Server. This offers a complete isolation of the OAM Server from the establishment of any unauthenticated network connection. Unauthenticated users cannot send malformed requests to the OAM Server.	No.
Communication channel	DCC consumes HTTP/HTTPS requests from the user, then communicates with the OAM Server across the Oracle Access Protocol (back channel), which can be SSL-enabled.	ECC communicates with both the user and the OAM Server across HTTP/HTTPS.
DCC login, error, and password pages	Dynamic pages general login/logout and password policy with the DCC are excluded automatically through the OHS httpd.conf/webgate.conf file--you do not need to configure a policy to exclude these. See the Webgate host in WEBGATE_HOME/webgate/ohs/oamsso/*, WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl, and WEBGATE_HOME/webgate/ohs/oamsso-bin/templates/* directory: Login page: /oamsso-bin/login.pl Logout: /oamsso-bin/logout.pl RSA SecurID login pages: /oamsso-bin/securid.pl Note: Update the Perl location in the first line of the login, logout, and securid scripts in /oamsso-bin. See Also: Table 16-24, "Credential Collector Password Pages". Chapter 42, "Integrating RSA SecurID Authentication with Access Manager" for details about login pages for this implementation. For details about customizing pages and messages, see the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.	Pages where the user enters her credentials arrive out of the box on the OAM Server and require no additional settings or changes. Login page: /pages/login.jsp Logout page: /pages/logout.jsp Error page: /pages/servererror.jsp Multi-step: /pages/mfa_login.jsp
Perl Scripts for DCC-based Login and Logout	Perl Scripts for DCC-based Login and Logout The path name of the Perl executable must be updated in Oracle-provided Perl scripts on the Webgate host WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl to be consistent with the actual location. Unix: The which command finds Perl on the OAM Server. For example: which perl /usr/bin/perl However, Perl scripts themselves point to: /usr/local/bin/perl Windows: The default Perl Interpreter specified in Oracle-provided Perl scripts will not be available. You must update the Perl Interpreter path in these scripts to actual path to Perl on your system.	N/A
Password policy enforcement	Yes. See "Locating and Updating DCC Forms for Password Policy"	Yes See: "Managing Global Password Policy"
Authentication scheme collection methods	DCC supports all challenge methods.	ECC supports all challenge methods. The ECC collects user credentials based on the challenge method of the Authentication Scheme and sends it back to OAM Server for validation.
Custom Authentication Plug-ins and Challenge Methods	Yes; same as ECC.	All challenge methods and multi-step authentication (Password Policy and other custom authentication plugins) are supported.
Single Step (Simple Form) Authentication	Yes; same as ECC.	Yes. Both the DCC and ECC handle this, where: All credentials are supplied in one simple form Upon credential validation and authentication, either success or failure status is returned This can be retried upon failure
Multi-Step Authentication	Yes. Both the DCC and ECC handle complex multi-factor (multi-step, iterative, and variable) Authentication processing. In this case: Not all required credentials are supplied at once Depending on the authentication status, PENDING state, expected credentials and context data are returned, expecting those credentials to be supplied in the next round Each intermediate step, submit required credentials and context data to feed authentication engine, until a success or failure status returned The Authentication plug-in can have multiple steps configured See "Understanding Multi-Level and Step-Up Authentication"	Yes. Both the DCC and ECC handle complex multi-factor (multi-step, iterative, and variable) Authentication processing.
Authentication Processing	The DCC does not restrict authentication functionality of the OAM Server in any way as compared to the ECC. The DCC: Handles authentication redirects from both 10g and 11g Webgates. Handles Form-based authentication, which consists of a challenge to the user for their credentials (simple form or multi-factor). Decrypts the authentication request message from the agent using the agent key; performs basic integrity checks; validates request time; and extracts all parameters from the request including request context. Constructs the authentication response message, including request context originally retrieved, encrypts obrar using the agent key. Decrypts the logout redirect request using the agent key to trigger logout processing.	During authentication: The ECC handles the request coming to the protocol binding layer (PBL), which converts it and sends it to the SSO Engine. The SSO Engine checks for a valid session and, if none, transfers control to the Authentication Engine. The Authentication Engine checks for resource protection and fetches the authentication scheme associated with the resource. The ECC interacts with the client, accepts the data, and submits this to the PBL.
Overriding the ECC	To deploy the DCC and override the ECC, an Administrator must perform the following tasks to specify the relevant DCC URLs and forms. OAM Agent registration: Allow Credential Collector Operations (enable for DCC) Authentication Module, Step Orchestration: Error (if Failure) Authentication Scheme: Challenge Redirect URL (DCC host and port) Authentication Scheme: Challenge URL /oamsso-bin/login.pl (DCC login pages) Authentication Scheme: Challenge Method Password Policy: Password Service URL for DCC (Default: /oamsso-bin/login.pl) See "Enabling DCC Credential Operations"	N/A
Logout Configuration	See "Configuring Logout When Using Detached Credential Collector-Enabled Webgate"	See "Configuring Centralized Logout for 11g Webgates"
Cookie/Token	DCCCtxCookie 11g Webgate: OAMAuthnCookie 11g Webgate: OAMRequestContext 10g Resource Webgate: ObSSOCookie See: "About Single Sign-On Cookies During User Login"	11g Webgate: OAMAuthnCookie 11g Webgate: OAM_REQ 11g Webgate: OAM_ID 11g Webgate: OAMRequestContext 10g Webgate: ObSSOCookie See: "About Single Sign-On Cookies During User Login"

16.5.3 Authentication Event Logging and Auditing

Authentication Success and Failure events are audited, in addition to administration events. Auditing covers creating, modifying, viewing, and deleting authentication schemes, modules, and policies. Information that is collected about the user who is authenticating includes:

• IP address

• User Login ID

• Time of Access

During logging (or auditing), user information, user sensitive attributes are not recorded. Secure data (user passwords, for example) are removed to avoid misuse.

See Also:

• Chapter 6, "Logging Component Event Messages"

• Chapter 8, "Auditing Administrative and Run-time Events."

• Chapter 9, "Monitoring Performance by Using Oracle Access Management Console"

16.6 Managing Native Authentication Modules

In Access Manager, each authentication scheme requires an authentication module.

Note:

Native authentication modules lack the flexibility to orchestrate two or more plug-ins to meet specialized authentication needs. Therefore, native authentication modules are targeted for deprecation in future releases. Oracle strongly recommends using plug-in based authentication modules as described "Orchestrating Multi-Step Authentication with Plug-in Based Modules".

This section provides the following information:

• About Native Access Manager Authentication Modules

• Viewing or Editing Native Authentication Modules

• Deleting a Native Authentication Module

16.6.1 About Native Access Manager Authentication Modules

Table 16-6 lists the Native Access Manager Authentication Modules.

Table 16-6 Native Authentication Modules

Module Name	Description
LDAP	Matches the credentials (username and password) of the user who requests a resource to a user definition stored in an LDAP directory server. An LDAP module is required for Basic and Form challenge methods. See Also: "Native LDAP Authentication Modules".
LDAPNoPasswordAuthModule	Matches the credentials (username and password) of the user who requests a resource to a user definition stored in an LDAP directory server. An LDAP module is required for Basic and Form challenge methods. See Also: "Native LDAP Authentication Modules".
Kerberos	Identifies the key tab file and krb5.configuration file names and Principal. Use this plug-in when configuring Access Manager for Windows Native Authentication, as described in Chapter 43. See Also: "Native Kerberos Authentication Module".
X509	Similar to the LDAPPlugin with additional properties that indicate which attribute of the client's X.509 certificate should be validated against the user attribute in LDAP. See Also: "Native X509 Authentication Module".
Custom Authentication Modules	This type of module relies on bundled plug-ins (or those that are developed using the Access Manager Authentication Extensibility Java API). This type of module generally uses more than one plug-in that you can orchestrate to ensure that each one performs a specific authentication function. Depending on the success or failure action defined for each plug-in, another authentication plug-in is called. See Also: "About Plug-in Based Modules for Multi-Step Authentication", and Oracle Fusion Middleware Developer's Guide for Oracle Access Management for details about developing and deploying plug-ins, custom authentication modules, and schemes that use custom modules.

See Also:

• "About Challenge Methods"

• Oracle Fusion Middleware Developer's Guide for Oracle Access Management for details about creating custom authentication plug-ins

16.6.1.1 Native Kerberos Authentication Module

The pre-configured Kerberos authentication module is illustrated in Figure 16-5. Additional details follow the figure.

Figure 16-5 Native Kerberos Authentication Module

Description of "Figure 16-5 Native Kerberos Authentication Module"

Table 16-7 describes the definition of the native Kerberos authentication module. You can use the existing, pre-configured Kerberos authentication module or create one of your own.

Table 16-7 Native Kerberos Authentication Module Definition

Element	Description
Name	The unique ID of this module, which can include upper and lower case alpha characters as well as numbers and spaces.
Key Tab File	The path to the encrypted, local, on-disk copy of the host's key, required to authenticate to the key distribution center (KDC). For example: /etc/krb5.keytab. The KDC authenticates the requesting user and confirms that the user is authorized for access to the requested service. If the authenticated user meets all prescribed conditions, the KDC issues a ticket permitting access based on a server key. The client receives the ticket and submits it to the appropriate server. The server can verify the submitted ticket and grant access to the user submitting it. The key tab file should be readable only by root, and should exist only on the machine's local disk. It should not be part of any backup, unless access to the backup data is secured as tightly as access to the machine's root password itself.
Principal	Identifies the HTTP host for the principal in the Kerberos database, which enables generation of a keytab for a host.
Krb Config File	Identifies the path to the configuration file that controls certain aspects of the Kerberos installation. A krb5.conf file must exist in the /etc directory on each UNIX node that is running Kerberos. krb5.conf contains configuration information required by the Kerberos V5 library (the default Kerberos realm and the location of the Kerberos key distribution centers for known realms).

16.6.1.2 Native LDAP Authentication Modules

Oracle provides two LDAP authentication modules:

• LDAP

• LDAPNoPasswordAuthModule

Both modules have the same requirements (Name and User Identity Store), as illustrated in Figure 16-6. Additional details follow the figure.

Figure 16-6 Native LDAP Authentication Module

Description of "Figure 16-6 Native LDAP Authentication Module"

Table 16-8 describes the elements in an LDAP authentication module. The same elements and values are also used in LDAPNoPasswordAuthnModule.

Note:

These standard LDAP Authentication Modules are targeted for deprecation. Future enhancements will not be available in standard modules. Oracle strongly recommends using plug-in based modules.

Table 16-8 Native LDAP Authentication Modules Definition

Element	Description
Name	A unique name for this module.
User Identity Store	The designated LDAP user identity store must contain any user credentials required for authentication by this module. The LDAP store must be registered with Access Manager. See Also: "Managing User Identity Stores". Multiple identity store vendors are supported. Upon installation, there is only one User Identity Store, which is also the designated System Store. If you add more identity stores and designate a different store as the System Store, be sure to change the LDAP module to point to the System Store. The authentication scheme OAMAdminConsoleScheme relies on the LDAP module for Administrator Roles and credentials. See Also: "Setting the Default Store and System Store" and "Administrator Lockout".

16.6.1.3 Native X509 Authentication Module

Access Manager provides a pre-configured X509 authentication module as a default. Administrators can also create new X509 authentication modules. In cryptographic terms, X.509 is a standard for digital public key certificates used for single sign-on (SSO). X.509 specifies standard formats for public key certificates, certificate revocation lists, and attribute certificates among other things.

With X.509 digital certificates you can assume a strict hierarchical system of certificate authorities (CAs) issuing the certificates. In the X.509 system, a CA issues a certificate that binds a public key to a particular Distinguished Name, or to an Alternative Name such as an e-mail address or a DNS-entry.

The trusted root certificates of an enterprise can be distributed to all employees so that they can use the company PKI system. Certain Web browsers provide pre-installed root certificates to ensure that SSL certificates work immediately.

Access Manager uses the Online Certificate Status Protocol (OCSP) Internet protocol to maintain the security of a server and other network resources. OCSP is used for obtaining the revocation status of an X.509 digital certificate. OCSP specifies the communication syntax used between the server containing the certificate status and the client application that is informed of that status.

When a user attempts to access a server, OCSP sends a request for certificate status information. OCSP discloses to the requester that a particular network host used a particular certificate at a particular time. The server returns a response of "current", "expired," or "unknown." OCSP allows users with expired certificates a configurable grace period, during which they can access servers for the specified period before renewing.

OCSP messages are encoded in ASN.1 and are usually transmitted over HTTP. The request and response characteristic of OCSP has led to the term "OCSP responders" when referring to OCSP servers. With Access Manager, the computer hosting the Oracle Access Management Console is the OCSP responder.

An OCSP responder can return a signed response signifying that the certificate specified in the request is 'good', 'revoked' or 'unknown'. If OCSP cannot process the request, it can return an error code.

Figure 16-7 Native X509 Authentication Module

Description of "Figure 16-7 Native X509 Authentication Module"

Table 16-9 describes the requirements of the native X509 authentication module.

Note:

This standard Authentication Module is targeted for deprecation. Future enhancements will not be available in standard modules. Oracle strongly recommends using plug-in based modules.

Table 16-9 X509 Authentication Module Definition

Element	Description
Name	Identifies this module definition with a unique name.
Match LDAP Attribute	Defines the LDAP distinguished name attribute to be searched against given the X509 Cert Attribute value. For example, if the certificate subject EMAIL is [e-mail] and it must be matched against the "mail" LDAP Attribute, an LDAP query must search LDAP against the "mail" attribute with a value "[e-mail] (cn). Default: cn
X509 Cert Attribute	Defines the certificate attribute to be used to bind the public key (attributes within subject, issuer scope to be extracted from the certificate: subject.DN, issuer.DN, subject.EMAIL, for example). See Also. Match LDAP Attribute earlier in this table.
Cert Validation Enabled	Enables (or disables if not checked) X.509 Certificate validation. When enabled, the OAM Server performs the certificate validation (rather than having the WebLogic server intercept and validate the certificate before passing it to the OAM Server). Access Manager performs the entire certificate path validation.
OCSP Enabled	Enables (or disables when not checked) the Online Certificate Status Protocol. Values are either true or false. For example: OCSP Enabled: true Note: OCSP Server Alias, OCSP Responder URL and OCSP Responder Timeout are required only when OCSP Enabled is selected.
OCSP Server Alias	An aliased name for the OSCSP Responder pointing to CA certificates in .oamkeystore file--a mapping between the aliased name and the actual instance name or the IP address of the OSCSP Responder instance.
OCSP Responder URL	Provides the URL of the Online Certificate Status Protocol responder. For example, OpenSSL Responder URL: http://localhost:6060
OCSP Responder Timeout	Specifies the grace period for users with expired certificates, which enables them to access OAM Servers for a limited time before renewing the certificate.

16.6.2 Viewing or Editing Native Authentication Modules

Users with valid Administrator credentials can use the following procedure to modify an existing authentication module. This includes changing the name of an existing module as well as changing other attributes.

Prerequisites

Modify each authentication scheme that references the module you will change, to use another authentication module if needed.

Note:

By default, the LDAP module is used in the authentication scheme that protects the Oracle Access Management Console. To ensure Administrator access, the LDAP module must point to the User Identity Store that is designated as the System Store. If you change the designated System Store, be sure to change the LDAP Module to reference the newly designated System Store.

To find, view, or edit an authentication module

1. From the Oracle Access Management Console, go to:

   
   System Configuration tab
   Access Manager section
   Authentication Modules node
   

2. Open the desired Authentication Modules page.

3. On the Authentication Modules page, modify information as needed:

   • Kerberos Module: See Table 16-7

   • LDAP Module: See Table 16-8

   • X509 Module: See Table 16-9 and Table 16-15

4. Click Apply to submit the changes and close the Confirmation window (or close the page without applying changes).

5. Add the updated authentication module to authentication schemes (or change to another authentication module in each authentication scheme that references this module), as described in "Managing Authentication Schemes".

16.6.3 Deleting a Native Authentication Module

Users with valid Administrator credentials can use the following procedure to delete an authentication module.

The following procedure is the same whether you are deleting a custom authentication module or a native module.

Prerequisites

In each authentication scheme that references the module to be deleted, specify another authentication module.

To delete an authentication module

1. In each authentication scheme that references this module, specify another authentication module.

2. From the Oracle Access Management Console, go to:

   
   System Configuration tab
   Access Manager section
   Authentication Modules node
   

3. Optional: Open the module to verify this is the module to remove, then close the page.

4. Click the desired module name, then click the Delete button.

5. Confirm removal (or dismiss the confirmation window to retain the module).

16.7 Orchestrating Multi-Step Authentication with Plug-in Based Modules

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.

Note:

Oracle strongly recommends using authentication plug-ins to create custom authentication modules.

This section provides the following topics:

• About Plug-ins and Multi-Step Authentication Module Creation

• About Plug-in Based Modules for Multi-Step Authentication

• Leveraging SubjectAltName Extension Data and Integrating with Multiple OCSP Endpoints

• Creating and Orchestrating Plug-in Based Multi-Step Authentication Modules

See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Access Management if you want to create custom authentication plug-ins.

16.7.1 Comparing Simple Form and Multi-Factor (Multi-Step) Authentication

Simple form-based authentication relies on the default embedded or optional detached credential collector and Web forms that process user logins with Access Manager authentication mechanisms. Simple form-based authentication is the default and does not require additional configuration unless you want to customize forms.

With simple form-based authentication:

• All credentials are supplied in one simple form

• Upon credential validation and authentication, either success or failure status is returned

• This can be retried upon failure

See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Access Management for details about customizing login pages and forms

For dynamic, multi-step authentication, Access Manager provides a number of plug-ins with which you can design and orchestrate your own customized authentication modules. Authentication plug-ins provide processing that meets your specific needs.

Also, Administrators can install multiple user identity stores for Access Manager. Each identity store can rely on a different LDAP provider. Each authentication plug-in can be configured to use a different user identity store.

Both the ECC and DCC handle complex multi-factor (multi-step, iterative, and variable) Authentication processing, where:

• Not all required credentials are supplied at once

• Depending on the authentication status, PENDING state, expected credentials and context data are returned, expecting those credentials to be supplied in the next round

• Each intermediate step, submit required credentials and context data for the authentication engine, until a success or failure status returned

• The Authentication plug-in can have multiple steps configured

Table 16-10 provides more information about these two forms of authentication.

Table 16-10 Simple Form versus Multi-Step Authentication

Authentication Method	Description
Simple form-based authentication	Simple form-based authentication relies on Credential Collectors (both ECC and DCC) and Web forms that process user logins using Access Manager authentication mechanisms. This is the default and does not require additional configuration unless you want to customize forms. See Also: Oracle Fusion Middleware Developer's Guide for Oracle Access Management for details about customizing login pages and forms
Multi-Step Authentication	Multi-step authentication requires a custom authentication module composed of two or more authentication plug-ins that transmit information to the backend authentication scheme several times during the login process. All information collected by the plug-in and saved in the context will be 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. Multi-Step authentication relies on: Authentication Chaining: You can chain multiple authentication plug-ins in a new authentication module, and add the module to an authentication scheme. Challenge Mechanism: Controls the way in which the required credentials are collected. Currently, this is tied to the authentication scheme. Both the ECC and DCC use the same challenge mechanisms. Credential Collection: Either the ECC or DCC can be used for multi-step authentication. (DCC provides greater flexibility for interactions with users or programmatic entities when collecting authentication-related information that involves several methods to establish the user's identity). See Also: "Adding PasswordPolicyValidationScheme to Authentication Policy for DCC" Oracle Fusion Middleware Developer's Guide for Oracle Access Management for details about custom authentication plug-ins

16.7.2 About Plug-ins and Multi-Step Authentication Module Creation

You can create custom plug-in based authentication modules using existing Access Manager plug-ins. You can also create your own plug-ins, as described in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

Each plug-in provides an individual piece of functionality that you can use alone or string together into a series of steps. The lifecycle of a plug-in centers around the ability to add plug-ins to the OAM Server and use the plug-ins to build features and work flows that act as extensions to the OAM Server. Each plug-in is deployed as a JAR file and each plug-in's configuration requirements must be given in XML format.

Note:

Plug-ins operate with either the default embedded credential collector (ECC) or the optional detached credential collector (DCC-enabled Webgate). Standard (native) Authentication Modules are targeted for deprecation; future enhancements will not be available in the standard modules. Oracle strongly recommends using plug-in based modules as described in "Orchestrating Multi-Step Authentication with Plug-in Based Modules".

Figure 16-8 shows out of the box plug-ins available from the Common Configuration section of the System Configuration tab on the Oracle Access Management Console. These plug-ins, and any that you create using the SDK and import, appear in a list when you add steps to build a custom authentication module.

Figure 16-8 Access Manager Plug-ins for Customized Authentication Modules

The Name generally defines the component that relies on the plug-in. The Description is optional. The Type column indicates the purpose of the plug-in. Activation Status lets you know if this is active and ready to use.

See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Access Management for details about building your own custom plug-ins. You can import new plug-ins, distribute, activate, deactivate, and remove custom plug-ins.

Whether you use an Oracle-provided plug-in or create one of your own, adding a plug-in when you create a custom authentication module is the same.

Each custom module requires the following types of information:

• General identifies the unique name and optional description for the individual plug-in.

• Steps identify the specific plug-ins to use, and their execution order, based on the configuration details of each plug-in (including the user identity store to use).

• Step Orchestration specifies the action to be taken on success or on failure or on error.

Figure 16-9 shows a Custom Authentication Module within the Access Manager section of the System Configuration tree. Each module provides three subtabs where you enter information for the module.

Figure 16-9 Creating Custom Authentication Modules: General

Description of "Figure 16-9 Creating Custom Authentication Modules: General "

Table 16-11 Describes the content of the General tab.

Table 16-11 General tab

Element	Description
Name	A unique name up to 60 characters.
Description	Optional; up to 250 characters.

Clicking the Steps tab opens a fresh page where you can add a new step. When you add a new Step, the following dialog box appears. Information that you enter is used to populate the table and Details sections of the page.

Figure 16-10 Adding a Step and Associating a Plug-in

Description of "Figure 16-10 Adding a Step and Associating a Plug-in"

Table 16-12 describes the information required when adding a new step. Each step requires a plug-in and each plug-in requires specific details for proper operation.

Table 16-12 Add New Step Entries, Steps Results Table, and Details Section

Element	Description
Step Name	The unique name you enter to identify this step, up to 60 characters.
Description	The optional description for this step, as entered when adding the step (up to 250 characters).
Plugin Name	The plug-in that you select for a particular step from the list of imported and activated plug-ins. See Also: Oracle Fusion Middleware Developer's Guide for Oracle Access Management for details about creating custom plug-ins.
Step Details	Plug-in configuration details must be specified to ensure proper operation. Details might differ depending the chosen plug-in and its requirements. See Also: Table 16-13.

Table 16-13 describes the Plug-in Parameter Details required by various plug-ins. Absent from this table are the plug-in exceptions (those plug-ins with no initial parameters): KerberosTokenIdentifier, FedAuthnRequestPlugin, and FedUserAuthenticationPlugin.

Table 16-13 Parameter Details for Various Plug-ins

Plug-in Parameter	Display Name	Description
KEY_IDENTITY_STORE_REF	Identity Store Name	Most plug-ins require this attribute to ensure that the appropriate user identity store is called during authentication. The following plug-in uses only this property: TAPAssertionPlugIn For additional Details required by plug-ins that employ this property, see: UserIdentificationPlugIn UserAuthenticationPlugIn UserPasswordPolicyPlugin TAPUserAuthenticationPlugin TenantDisambiguationPlugin
UserIdentificationPlugIn
KEY_LDAP_FILTER	LDAP Filter	The search filter required to identify the user. Only standard LDAP attributes can be used when defining an LDAP search filter.
KEY_SEARCHBASE_URL	LDAP Searchbase	The search base required for the query. The node in the directory information tree (DIT)) under which user data is stored; the highest possible base for all user data searches.
UserAuthenticationPlugIn
KEY_PROP_AUTHN_EXCEPTION	Propagate LDAP errors	Enables (or disables) propagation of LDAP errors. UserAuthenticationPlugIn employs this attribute.
UserPasswordPolicyPlugin
PLUGIN_EXECUTION_MODE	Mode of Operation	The execution mode of plug-in (UserPasswordPolicyPlugin). Depending upon the configuration, this plug-in can operate either alone or with other default plug-ins. Values are one of the following: PSWDONLY: Default. The most preferred configuration where only the password status is determined. The ID and authentication must be performed using the UserIdentification and UserAuthentication Plugins. AUTHWITHPSWD: Both authentication and password are performed using this plug-in. AUTHONLY: Only the user identification and authentication is performed using this plug-in
POLICY_SCHEMA	Policy Schema To Use	Specifies the schema for the password service (used with UserPasswordPolicyPlugin). Only OAM10G is supported. Default: OAM10G
NEW_USERPSWD_BEHAVIOR	Force Password Change on First Login	Configures retroactive behavior of the new-user password-policy. Used with UserPasswordPolicyPlugin.Values are either: FORCEPASSWORDCHANGE: Forces a password change. NOFORCEPASSWORDCHANGE: The password policy change does not affect user passwords that are already set. Default: FORCEPASSWORDCHANGE
DISABLED_STATUS_SUPPORT	Disabled Account Status Support	Specifies whether the disabled status is to be supported and acted upon in this password service. Valid values are either True or False. Default: TRUE
URL_ACTION	Password Management Action URL	Specifies the URL to which the user is sent for password management. The type of servlet action needed for redirecting the user to the specific password page for expiry and warning pages. Values can be either: REDIRECT_POST REDIRECT_GET FORWARD Default: REDIRECT_POST
FedUserProvisioningPlugin
KEY_USER_RECORD_ATTRIBUTE_LIST	List of User Attributes	For Federation. Comma-separated list of assertion attributes required to create the user record.
KEY_PROVIDERID_ATTRIBUTE_NAME	Partner Attribute Name	For Federation. The attribute name of the LDAP user record whose value will be set to the Partner's Identity Provider ID when provisioning the user. This field is optional and if empty, the Partner's Identity Provider ID will not be set in the LDAP user record.
KEY_USERID_ATTRIBUTE_NAME	User UserID Attribute	For Federation. Name of the attribute in the assertion attributes that is used as the LDAP UserID.
TAPIdentifyPlugIn
KEY_TAP_RETURN_ATTRIBUTE	Username Mapping Attribute	Name of the attribute used for account linking by TAPIdentifyPlugIn.
SequentialPlugInExecutionStrategy
StrategyName	Orchestration Strategy	Name of the plugin orchestration strategy required by SequentialPlugInExecutionStrategy.
KerberosTokenAuthenticator
KEY_KEYTAB_FILE	Location of Keytab file	Name of the file containing Kerberos principals and encrypted keys required by KerberosTokenAuthenticator
KEY_PRINCIPAL	OAM Service Principal	Your OAM Account SPN, required by KerberosTokenAuthenticator.
KEY_KRB_CONFIG_FILE	Location of Kerberos Configuration file	Location of the Kerberos configuration properties file, required by KerberosTokenAuthenticator.
KEY_DOMAIN_DNS2DN_MAP	AD Domain DNS Names to DN Mapping	Comma-separated list of Active Directory DNS Domains to DN mappings required by KerberosTokenAuthenticator.
X509CredentialExtractor
KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT	User Mapping Attribute	X509 certificate Attribute to be used for user mapping required by X509CredentialExtractor.
KEY_IS_CERT_VALIDATION_ENABLED	Certificate Validation	Enable or disable X.509 certificate validation, required by X509CredentialExtractor.
TAPRequestPlugin
TAPS2PVersion	Integration Protocol Version	Token version for Integration.
TAPPartnerId	Integration PartnerId	Integration Partner Identifier.
TAPChallengeURL	Partner Integration Endpoint URL	Remote Partner End Point URL.
TAPUserAuthenticationPlugin
KEY_USERNAME_ATTRIBUTE	Username Mapping Attribute	Name of the attribute used for account linking required by TAPUserAuthenticationPlugin
KEY_CHECK_TOKEN_EXPIRY	Enable Token Expiration Checking	Enable or disable Integration token expiration.
TenantDisambiguationPlugin
KEY_FEDERATED_TENANTS	FederatedTenantNames	Optional names of tenants (comma separated) for whom federated authentication is enabled. Plugin will check with Federation engine if tenant names are not mentioned.
RSA SecurID Plugin
username	Username Parameter	Name of the username plugin parameter required by RSA SecurID Plugin.
passcode	Passcode Parameter	Name of the passcode plugin parameter required by RSA SecurID Plugin.
nexttoken	Next Token Parameter	Name of the next token plugin parameter required by RSA SecurID Plugin.
newpin	New PIN Parameter	Name of the new pin plugin parameter required by RSA SecurID Plugin.
confirmnewpin	Confirm New PIN Parameter	Name of the confirm new pin plugin parameter required by RSA SecurID Plugin.
HTTPTokenExtractor
KEY_HEADER_PROPERTY	HTTP Header Names	Comma separated list of HTTP Headers.
KEY_COOKIE_PROPERTY	HTTP Cookie Names	Comma separated list of Cookies.

Figure 16-11 illustrates the Steps subtab and Details section for a custom authentication module. When adding Steps, there is no data to display in the table. However, when you add one or more Steps the table the Details sections are populated.

Figure 16-11 Plug-in Based Authentication Module Steps and Details

Description of "Figure 16-11 Plug-in Based Authentication Module Steps and Details"

Figure 16-12 illustrates the Steps Orchestration subtab of a custom authentication module, which is populated by information for each defined step (and the action you choose for each operational condition).

Figure 16-12 Steps Orchestration for Plug-in Based Authentication Modules

Description of "Figure 16-12 Steps Orchestration for Plug-in Based Authentication Modules"

Table 16-14 describes the elements on the Steps Orchestration subtab. The lists available for OnSuccess, OnFailure, and OnError include the following choices:

• success

• failure

• StepName (any step in the module can be selected as the action for an operational condition)

Table 16-14 Steps Orchestration Subtab

Element	Description
Initial Step	Choose the starting step from those listed. The list includes only those steps defined for this module.
Name	Each step added to this module is listed by the name that was entered when the step was added.
Description	The optional description for this step, entered when this step was added.
OnSuccess	The action selected for successful operation. A list provides actions you can choose: Success Failure StepName (activates the next step)
OnFailure	The action selected for failure of this step. A list provides actions you can choose: Success Failure StepName (activates the next step)
OnError	The action selected for an error when executing this step. A list provides actions you can choose: Success Failure StepName (activates the next step)

16.7.3 About Plug-in Based Modules for Multi-Step Authentication

Figure 16-13 lists the currently available native plug-in based Authentication modules.

Figure 16-13 Oracle-provided Plug-in Based Authentication Modules

Following topics describe several of the native Custom modules provided with pre-populated plug-ins. You can use these to orchestrate your own custom authentication modules:

• KerberosPlugin

• LDAPPlugin

• X509Plugin

• Password Policy Validation Module and Plug-ins

See Also:

• Table 16-13, "Parameter Details for Various Plug-ins"

• Example: How to leverage the SubjectAltName extension data and integrate with multiple OCSP Endpoints

KerberosPlugin

Use this plug-in when configuring Access Manager for Windows Native Authentication, as described in Chapter 43.

Figure 16-14 shows the KerberosPlugin module that is bundled with Access Manager 11g. This is a credential mapping module that matches the credentials (username and password) of the user who requests a resource to the encrypted "kerberos ticket".

Figure 16-14 KerberosPlugin

Description of "Figure 16-14 KerberosPlugin"

Figure 16-15 shows the default steps and details. Figure 16-16 shows the orchestration of the steps and conditions.

Figure 16-15 Default KerberosPlugin Steps and Details

Description of "Figure 16-15 Default KerberosPlugin Steps and Details"

Figure 16-16 Default KerberosPlugin Steps and Orchestration

Description of "Figure 16-16 Default KerberosPlugin Steps and Orchestration"

LDAPPlugin

Figure 16-17 shows the LDAPPlugin module that is bundled with Access Manager. By default, LDAPPlugin has 2 steps, shown in Figure 16-18. Figure 16-19 shows the default orchestration of steps for LDAPplugin.

Figure 16-17 LDAPPlugin

Description of "Figure 16-17 LDAPPlugin"

Figure 16-18 Default LDAPPlugin Steps and Details

Description of "Figure 16-18 Default LDAPPlugin Steps and Details"

Figure 16-19 Default Orchestration of Steps for LDAPplugin

Description of "Figure 16-19 Default Orchestration of Steps for LDAPplugin"

X509Plugin

Figure 16-20 shows the X509Plugin module that is bundled with Access Manager 11g. The X509Plugin is similar to the LDAPPlugin with additional properties that indicate which attribute of the client's X.509 certificate should be validated against the user attribute in LDAP. Figure 16-21 shows default steps and details for this plug-in. Figure 16-22 shows the default orchestration of steps for the X509Plugin.

Figure 16-20 X509Plugin

Description of "Figure 16-20 X509Plugin"

Figure 16-21 X509Plugin Default Steps and Details

Description of "Figure 16-21 X509Plugin Default Steps and Details"

With this plug-in, the root and sub CA certificates must be added to the DOMAIN_HOME/config/fmwconfig/amtruststore because the X509CredentialExtractor plug-in loads certificates from this location.

Table 16-15 lists the stepX509 values for Subject and Subject Alternative Names. Such processing is only supported when the X509Plugin is used.

See Also:

• Table 16-13, "Parameter Details for Various Plug-ins"

• Example: How to leverage the SubjectAltName extension data and integrate with multiple OCSP Endpoints

Table 16-15 X509 Step Details (KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT)

issuer.D	Subject
subject.	EDIPI Note: EDIPI refers to the Electronic Data Interchange Personal Identifier.
subjectAltName.	OTHER_NAME (FASC-N) Note: FASC-N refers to the Federal Agency Smart Credential Number.
subjectAltName.	RFC822_NAME
subjectAltName.	UNIFORM_RESOURCE_IDENTIFIER

Figure 16-22 Default Orchestration for X509Plugin Steps

Description of "Figure 16-22 Default Orchestration for X509Plugin Steps"

See Also:

"Leveraging SubjectAltName Extension Data and Integrating with Multiple OCSP Endpoints"

Password Policy Validation Module and Plug-ins

Oracle provides a Password Policy Validation Module that employs the following plug-ins as individual steps in the authentication process:

• User Identification Step

• User Authentication Step

• User Password Status Step

Figure 16-23 shows the Steps tab. Additional details follow the figure.

Figure 16-23 Password Policy Validation Module Plug-ins

Figure 16-24 shows the Steps Orchestration page for the Password Policy Validation Module plug-ins, which is self explanatory.

See Also:

• Table 16-13, "Parameter Details for Various Plug-ins"

• "Understanding Password Policy"

Figure 16-24 Steps Orchestration: Password Policy Validation Plug-ins

16.7.4 Leveraging SubjectAltName Extension Data and Integrating with Multiple OCSP Endpoints

Access Manager 11g support for personal identity verification (PIV) cards (a United States Federal smart card), is to use FASC-N and EDIPI attributes from the SubjectaltName extension to map the user during X.509 authentication. While multiple OCSP providers are not supported, you can use an OCSP Gateway or write a custom authentication plug-in that uses the OSDT OCSP APIs to validate against multiple OCSP providers.

The following functionality is available only with the X.509 Plug-in (not the X.509 Authentication module). The Plug-in configuration specifies the LDAP attribute to which the extracted attribute from the X.509 client certificate will be mapped.

Example: How to leverage the SubjectAltName extension data and integrate with multiple OCSP Endpoints

1. From the Oracle Access Management Console, edit the existing X509Plugin (or create a custom X509 plug-in) as described here:

   
   System Configuration tab
   Access Manager section
   Authentication Modules node
   Custom Authentication Modules node
   X509plugin

   See Also:

   "Creating and Orchestrating Plug-in Based Multi-Step Authentication Modules"

   General Tab:

   1. Name: CustomX509Plugin.

   2. Description: Custom Plug-in for X509.

   Steps Tab:

   1. Click + to add a step to the plug-in.

   2. Enter a Name and Description, then select the X509CredentialExtractor plug-in.

   Step Details:

   1. KEY_IS_CERT_VALIDATION_ENABLED true.

   2. KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT (Table 16-15): subject.EDIPI, subjectAltName.OTHER_NAME (FASC-N), subjectAltName.RFC822_NAME, subjectAltName.UNIFORM_RESOURCE_IDENTIFIER

   3. Click the Save button.

   Add Another Plug-in:

   1. Click + to add a different plug-in.

   2. Enter the Name, Description, and select UserIdentificationPlugin

   Step Details for Second Plug-in:

   1. Set KEY_IDENTITY_STORE_REF to the required identity store.

   2. Add the LDAP filter to the KEY_LDAP_FILTER attribute. For example:

      (&(uid= 
      Unknown macro: {subject.CN} 
      )(mail=
      Unknown macro: {subject.E} 
      ))
      

   3. Add the user search base, if required, to the KEY_SEARCH_BASE_URL attribute.

   4. Click the Save button.

   5. Proceed to Step Orchestration tab (Step2).

2. Orchestrate Steps:

   1. Initial Step: Select the X509CredentialPlugin Step from the drop down.

   2. On Success: X509CredentialPlugin step, select the UserIdentificationPlugin Step from the drop down list.

   3. On Success: UserIdentificationPlugin step, select Success from the drop down list.

   4. On Failure: Select Failure for both X509CredentialPlugin and UserIdentificationPlugin steps.

   5. On Error: Select Failure for both X509CredentialPlugin and UserIdentificationPlugin steps.

   6. Click the Apply button and review the confirmation window stating that the plug-in has been created successfully.

3. Set up the Certificate Validation Module for Certificate Validation and Revocation using OCSP.

   See Also:

   "Managing Global Certificate Validation and Revocation"

   1. From the Oracle Access Management Console System Configuration tab, Common Configuration section, select Certificate Validation.

   2. In the Certificate Revocation list section, confirm that Enabled is checked, then click Save.

   3. In the OCSP/CDP section, enable OCSP, enter the OCSP URL and the Subject of the OCSP Server's certificate, then click Save.

   4. On the command line, use the Java keytool application to import the trusted certificates into the $DOMAIN_HOME/config/fmwconfig/amtruststore keystore, as trusted certificate entries.

      Note:

      Initially the keystore is empty; its password is set the first time the Java keytool application is used.

16.7.5 Creating and Orchestrating Plug-in Based Multi-Step Authentication Modules

Users with valid Administrator credentials can use the following procedure to create custom authentication plug-in module that uses one or more authentication plug-ins.

This procedure outlines general steps for any authentication module (with sample information to configure an authentication X509 module for use with the Online Certificate Status Protocol (OCSP) to maintain the security of a server and other network resources).

See Also:

"Example: How to leverage the SubjectAltName extension data and integrate with multiple OCSP Endpoints".

Prerequisites

Ensure that any user identity store associated with the module is running and includes the required user population.

To create a custom authentication module using bundled plug-ins

1. From System Configuration tab, Access Manager section, expand the Authentication Modules node.

2. Create New:

   1. Click the Custom Authentication Module node.

   2. Click the Create (+) button.

   3. Add General Information: Name and optional Description. For example: CustomX509Plugin and Plugin for X509, respectively.

      Click Apply to save general information.

3. Add Steps:

   1. Click the Steps subtab.

   2. Click the Add (+) button above the Steps table.

   3. In the Add New Step dialog box, enter a unique Step Name and optional Description.

   4. Browse for and select the desired plug-in name (X509CredentialExtractor, for instance) and click OK.

   5. Confirm information in the results table.

   6. Repeat b through e to add other steps until you have listed all required plug-ins for your module.

4. Define Step Details: Use appropriate values for requested parameters (Table 16-12, Table 16-13, Table 16-16, "Managing Custom Plug-ins Actions" and "Example: How to leverage the SubjectAltName extension data and integrate with multiple OCSP Endpoints"):

   1. Click a StepName in the table to reveal required details, enter appropriate values for the requested details.

   2. Validate User Cert using OCSP:

      Confirm that KEY_IS_CERT_VALIDATION_ENABLED is set to true.

      Add the certificate attributes to be extracted with KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT (Table 16-15):

      subject.EDIPI
      subjectAltName.OTHER_NAME (FASC-N)
      subjectAltName.RFC822_NAME
      subjectAltName.UNIFORM_RESOURCE_IDENTIFIER
      

   3. Click the Save button.

   4. Repeat to configure each step appropriately.

   5. Ensure that users are provisioned in any user identity stores assigned in the steps.

5. Orchestrate Steps: See Table 16-14 as you perform following steps.

   1. Click the Steps Orchestration subtab.

   2. From the InitialStep list, choose the name of the first step to be used.

   3. Select a StepName in the table.

   4. From the OnSuccess List, choose a condition (success or failure) or a step name.

   5. From the OnFailure List, choose the desired condition or a StepName.

   6. From the OnError List, choose the desired condition or a StepName.

   7. Repeat Steps c through f to orchestrate operations for each plug-in this module.

   8. Review your orchestration.

6. Initiate Strategy Validation: Click Apply to initiate validation of your orchestration strategy:

   • Successful Strategy: The orchestration strategy is applied and the module is ready to include in an authentication scheme. Continue with Steps 9 and 10.

   • Invalid Strategy: Click OK in the Error box, then edit your OnSuccess, OnFailure, OnError strategies (or add or remove plug-ins) to correct the problem. Repeat this step until your strategy is successful.

7. In the navigation tree, confirm the new Custom Authentication Module is listed, and then close the page when you finish.

8. Use your custom module in an authentication scheme, as described in "Managing Authentication Schemes".

16.8 Deploying and Managing Individual Plug-ins for Authentication

This section provides the following topics:

• About Managing Your Own Authentication Plug-ins

• Deploying and Managing Individual Plug-ins for Authentication

• Deleting Your Custom Authentication Plug-ins

16.8.1 About Managing Your Own Authentication Plug-ins

Using information in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management, custom authentication plug-ins can be created and used to define customized multi-step authentication modules.

After development, the plug-in must be deployed on the AdminServer, as a JAR file, which is validated automatically. After validation, an Administrator can configure and distribute the plug-in using the Oracle Access Management Console.

The server processes the XML configuration file within the plug-in JAR file to extract data about the plug-in. After the plug-in is imported, an Administrator can see and modify the various plug-in states based on information available from the AdminServer.

Figure 16-25 illustrates the Plug-ins Node under the Common Configuration section of the System Configuration tab, and the Plugins page. This Plugins page includes a tool bar with command buttons, most of which operate on the plug-in that is selected in the table. The table provides information about the existing custom plug-ins and their state. The Plugin Details section at the bottom of the page reflects configuration details for the selected plug-in the table.

Figure 16-25 Plug-ins Page

Administrators control plug-in states using the command buttons across the table at the top of the Plugins page, as described in Table 16-16.

Table 16-16 Managing Custom Plug-ins Actions

Action Button	Description
Import Plugin...	Adds the plug-in JAR file to the AdminServer DOMAIN_HOME/oam/plugins and begins plug-in validation. Same JAR Name: If the new plug-in JAR name (in DOMAIN_HOME/oam/plugins) matches an existing plug-in JAR name (in DOMAIN_HOME/config/fmwconfig/oam/plugins), Oracle Access Manager extracts new configuration metadata from the XML file in the JAR (in DOMAIN_HOME/oam/plugins) and checks the version of the new plug-in. XML Version: If the new plug-in XML version (in DOMAIN_HOME/oam/plugins) is greater than the existing XML version (in DOMAIN_HOME/config/fmwconfig/oam/plugins), validation is successful. Otherwise, "invalid plugin name with invalid version" is returned and the new plug-in JAR is removed (from DOMAIN_HOME/oam/plugins). Different JAR Name: If the new plug-in JAR name (in DOMAIN_HOME/oam/plugins) is different then existing plug-in JAR names (in DOMAIN_HOME/config/fmwconfig/oam/plugins), the new plug-in JAR is uploaded and validation is successful. On Success: Status is reported as "Uploaded" (even if an OAM Server is down). If all registered OAM Servers report "Uploaded", then the status on AdminServer is also "Uploaded". On Failure: Status is reported as "Upload Failed" See Also: "About the Custom Plug-in Life Cycle" in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management
Distribute Selected ...	Propagates the plug-in to all registered OAM Servers. Sets the plug-in flag in oam-config.xml to "Distribute=true". Starts the distribution listener and notification mechanism between AdminServer and OAM Servers Distributes the plug-in JAR from AdminServer node to each OAM Server node under DOMAIN_HOME/config/fmwconfig/oam/plugins On Success: Status is reported as "Distributed" (even if an OAM Server is down). If all registered OAM Servers report "Distributed", then the status on AdminServer is also "Distributed". On Failure: Status is reported as "Distribution Failed"
Activate Selected ...	After successful distribution the plug-in can be activated on all registered OAM Servers. Activation: Updates the plug-in flag in oam-config.xml to "Activate=true" Starts the Message listener and notification mechanism between AdminServer and OAM Servers AdminServer sends message "Activate" to all registered OAM Servers On Success: Status is reported as "Activated" (even if an OAM Server is down). If all registered OAM Servers report "Activated", then the status on AdminServer is also "Activated". On Failure: Status is reported as "Activation Failed" Following activation on all OAM Servers, the plug-in can be used and executed in any authentication module construction or orchestration.
Deactivate Selected ...	Following plug-in activation, an Administrator can choose to deactivate the plug-in: if the plug-in is not used in any authentication module or scheme, for example. The selected plug-in from all registered OAM Servers. Deactivate: Updates the plug-in flag in oam-config.xml to "De-activate=true" Starts the Distribution listener and notification mechanism between AdminServer and OAM Servers Removes the plug-in JAR from AdminServer and each registered OAM Server (DOMAIN_HOME/config/fmwconfig/oam/plugins) AdminServer sends message "De-activation" to all registered OAM Servers OAM Servers send status message to AdminServer using the "Message" listeners on both AdminServer and OAM Server On Success: Status is reported as "De-activation" (even if an OAM Server is down). If all registered OAM Servers report "De-activation", then the status on AdminServer is also "De-activation". Plug-in configuration is removed from oam-config.xml. Note: After deactivation, the plug-in cannot be used or executed in any authentication module or orchestration. On Failure: Status is reported as "De-activation Failed"
Remove Selected ...	Following plug-in deactivation, an Administrator can delete the selected plug-in. During this process, Oracle Access Manager: Delete: Updates the plug-in flag in oam-config.xml to "Remove=true" Starts the Distribution listener and notification mechanism between AdminServer and OAM Servers Removes the plug-in JAR from AdminServer and each registered OAM Server (DOMAIN_HOME/config/fmwconfig/oam/plugins) AdminServer sends message "Activate" to all registered OAM Servers On Success: Status is reported as "Removed" (even if an OAM Server is down). If all registered OAM Servers report "Removed", then the status on AdminServer is also "Removed". Plug-in configuration is removed from oam-config.xml. On Failure: Status is reported as "Removal Failed"

Table 16-17 describes elements in the Plugins status table.

Table 16-17 Plugins Status Table

Element	Description
Plugin Name	Extracted from the Plugin name element of the XML metadata file.
Description	Extracted from the description element of the XML metadata file.
Activation Status	Reported activation status based on information from AdminServer.
Type	Extracted from the type element of the XML metadata file.
Last Updated on	Extracted from the creation date element of the XML metadata file.
Last Updated by	Extracted from the author element of the XML metadata file.

In the Plugin Details section of the page, the Activation Status is maintained by the AdminServer, as shown in Table 16-17.

Figure 16-26 Plugin Details: Activation Status of Selected Plug-in

Depending on your plug-in, various configuration details are extracted from the configuration element of the XML metadata file to populate Configuration Parameters in the Plugin Details section. Examples are shown in Table 16-18; see also, Table 16-13.

Table 16-18 Example of Plugin Details Extracted from XML Metadata File

Configuration Element	Description
DataSource	- <configuration> - <AttributeValuePair> <Attribute type="string" length="20">DataSource</Attribute> <mandatory>true</mandatory> <instanceOverride>false</instanceOverride> <globalUIOverride>true</globalUIOverride> <value>jdbc/CISCO</value> <AttributeValuePair> <configuration>
Kerberos Details	Defines Kerberos details for this plug-in to use.
User Identification Details	Defines the User Identity Store and filter details for this plug-in to use.
User Authentication Details	Defines the User Identity Store for this plug-in to use.
X.509 Details	Defines the certificate details for this plug-in to use.

16.8.2 Making Custom Authentication Plug-ins Available for Use

Users with valid Administrator credentials can perform the following task to add, validate, distribute, and activate a custom plug-in.

Prerequisites

Developing a custom plug-in as described in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management

To make available for use a custom authentication plug-in

1. Import the Plug-in:

   1. Go to the Oracle Access Management Console and log in, as usual. For example:

      https://hostname:port/oamconsole/
      

   2. From the System Configuration tab, Common Configuration section, click Plugins and then click Open from the Actions menu.

   3. Click the Import Plugin button.

   4. In the Import Plugin dialog box, click Browse and select the name of your plug-in JAR file.

      
      

   5. Review the message in the dialog box, then click Import.

      The JAR file is validated as described in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

2. Configure Parameters: Expand the Plugin Details section, click Configuration Parameters, and enter appropriate information as needed. For example:

   
   

3. Distribute the Plug-in to OAM Servers:

   1. In the Plugins table, click your plug-in name to select it.

   2. Click the Distribute Selected button, then check its Activation Status.

      
      

4. Activate the Plug-in (and the custom plugin implementation class) so it is ready to be used by OAM Server:

   1. In the Plugins table, click your plug-in name to select it.

   2. Click the Activate Selected button, then check its Activation Status.

      
      

5. Perform the following tasks as needed:

   • Checking an Authentication Plug-in's Activation Status

   • Deleting Your Custom Authentication Plug-ins

   • Creating and Orchestrating Plug-in Based Multi-Step Authentication Modules

16.8.3 Checking an Authentication Plug-in's Activation Status

Users with valid Administrator credentials can perform the following task to add, validate, distribute, and activate a custom plug-in.

Prerequisites

Making Custom Authentication Plug-ins Available for Use

To check the activation status of a custom authentication plug-i

1. From the System Configuration tab, Common Configuration section, click Plugins and then click Open from the Actions menu.

2. In the Plugins table, click the desired plug-in name to select it.

3. Server Instance Name: Expand the Plugin Details section and click Activation Status to display the location and status of the plug-in. For example:

   
   

4. Perform the following tasks as needed:

   • Deleting Your Custom Authentication Plug-ins

   • Creating and Orchestrating Plug-in Based Multi-Step Authentication Modules

16.8.4 Deleting Your Custom Authentication Plug-ins

Users with valid Administrator credentials can use the following procedure to deactivate and then delete a custom plug-in.

When an Administrator deletes a custom authentication plug-in, its name is not removed from the list of plug-ins. To delete the plug-in (for the purpose of re-importing the same plug-in later), the Administration must stop the WebLogic Server and edit the oam-config.xml manually.

Prerequisites

The plug-in must have been added and available in the console

To delete a custom authentication plug-in

1. Go to the Oracle Access Management Console and log in, as usual. For example:

   https://hostname:port/oamconsole/
   

2. From the System Configuration tab, Common Configuration section, open Plugins.

3. Deactivate the Plug-in: You must perform this before removing a plug-in.

   1. In the Plugins table, click your plug-in name to select it.

   2. Click the Deactivate Selected button, then check the plug-ins Activation Status.

4. Delete a Deactivated Plug-in:

   1. In the Plugins table, click your plug-in name to select it.

   2. Click the Delete Selected button.

   3. Stop the WebLogic Administration Server, locate and edit oam-config.xml manually to remove the deactivated plug-in, and then restart the WebLogic Administration Server.

5. Perform the following tasks as needed:

   • Making Custom Authentication Plug-ins Available for Use

   • Creating and Orchestrating Plug-in Based Multi-Step Authentication Modules

16.9 Managing Authentication Schemes

Access to a resource or group of resources can be governed by a single authentication process known as an authentication scheme. An authentication scheme is a named component that defines the challenge mechanism required to authenticate a user. Each authentication scheme must also include a defined authentication module (standard or custom, as described in "Deploying and Managing Individual Plug-ins for Authentication").

When you register a partner (either using the console or the remote registration tool), the Application Domain that is created is seeded with a policy that uses the authentication scheme that is set as the default scheme. You can choose any of the existing authentication schemes as the default for use during policy creation.

You can also create a new authentication scheme, copy an existing definition to use as a template, modify a definition, or delete the definition. The copy uses a default name that is based on the original. For example, if you copy the scheme named KerberosScheme, the copy is named Copy of KerberosScheme.

This section is divided into the following topics:

• About Authentication Schemes and Pages

• Understanding Multi-Level and Step-Up Authentication

• Creating an Authentication Scheme

• Viewing, Editing, or Deleting an Authentication Scheme

• Searching for an Authentication Scheme

16.9.1 About Authentication Schemes and Pages

All authentication schemes include the same elements with differing values. Figure 16-27 shows the default LDAPScheme page as an example. The Authentication Schemes navigation tree lists other default schemes that are delivered.

Figure 16-27 Default LDAPScheme Page

Description of "Figure 16-27 Default LDAPScheme Page"

Table 16-19 provides information about each of the elements and values in any authentication scheme. Use the Set as Default button to make this the default scheme.

Table 16-19 Authentication Scheme Definition

Element	Description
Name	The unique name for this scheme, which appears in the navigation tree. See Also:"Pre-configured Authentication Schemes"
Description	The optional description, up to 200 characters, that explains the use of this scheme.
Authentication Level	The trust level of the authentication scheme. This reflects the challenge method and degree of trust used to protect transport of credentials from the user. The trust level is expressed as an integer value between 0 (no trust) and 99 (highest level of trust). Note: Level 0 is unprotected. Only unprotected resources can be added to an Authentication Policy that uses an authentication scheme at protection level 0. For more information, see Table 17-1, "Resource Definition Elements". Note: After a user is authenticated for a resource at a specified level, the user is automatically authenticated for other resources in the same Application Domain or in different Application Domains, if the resources have the same or a lower trust level as the original resource. See Also: "About Multi-Level and Step-Up Authentication".
Default	A non-editable box that is checked when the Set as Default button is clicked.
Challenge Method	One challenge method must be selected from those listed as available: Form Basic (LDAP) X509 (Certificate) WNA (Windows Native Authentication) None DAP OAM10g See Also: "About Challenge Methods"
Challenge Redirect URL	This URL declares the end point referencing the Credential Collector (ECC or DCC). For example: ECC: /oam/server DCC: http://<dcc-host:port>/ See Also: "About Host Identifiers" "Configuring 11g Webgate and Authentication Policy for DCC"
Authentication Module	Identifies the pre-configured authentication module to be used to challenge the user for credentials. The module or plug-in specified here identifies the exact user identity store to be used. FederationMTPlugin FederationPlugin Kerberos Plugin (Authentication Modules and Custom Authentication Module) MTLDAPBasic MTLDAPPlugin OIFMTLDAPPlugin Password Policy Validation Module TAPModule X509 Plugin (under the X509 Authentication Modules node) See also "Managing Native Authentication Modules" and "Orchestrating Multi-Step Authentication with Plug-in Based Modules".
Challenge URL	This URL is associated with the designated Challenge Method (FORM, for instance). FORM-based, out of the box authentication scheme (LDAPScheme and LDAPNoPasswordValidationScheme), Challenge URL is "/pages/login.jsp". The context type and context values are used to build the final URL. X509-based Challenge URL takes the form: https://managed_server_host:managed_server_ssl_port/oam/CredCollectServlet/X509 Note: The default Challenge URL is based on the credential collector embedded with the OAM Server (ECC). If you are using detached credential collector-enabled Webgate and related DCC pages installed with Webgate, see "Configuring 11g Webgate and Authentication Policy for DCC".
Challenge Parameters	Supported challenge parameters are discussed in "About Challenge Parameters for Authentication Schemes".
For schemes using Challenge Method FORM, X509, or DAP	Only Schemes with the Challenge Method of FORM, X509, or DAP include the following additional elements. Other schemes use defaults that require no change.
Context Type	Used to build the final URL for the Embedded Credential Collector (ECC only, DCC does not use this) based on the following possible values: default: The Context Value is used to construct the final URL to forward to for credential collection. For example: with a challenge URL of "/pages/login.jsp" and a context value of /oam, the server forwards to "/oam/pages/login.jsp" for credential collection by the ECC. customWar: If a customized credential collector page "customlogin.jsp" is deployed in a WAR file (with context root, "custom") within the same domain, it should be used to collect credentials. Then set the following values to have server forward to the WEB application page "/custom/customlogin.jsp" to collect credentials: challenge_url = "/customlogin.jsp" contextType="customWar" contextValue="/contextroot of custom application" customHtml: A custom html credential collector page. This file can be placed in a location that is accessible to the application. Set the following values to have the server forward to the custom servlet provided to read the html file and render the page: challenge_url = "/CustomReadServlet" contextType="customHtml" contextValue="html file location" external: If the login page is external, the file can be placed in a location that is accessible to the application. Set the following values to have the server redirect to the challenge URL (the fully-qualified URL of the external credential collector page) for credential collection. The username and password are collected by the external form (HTML or jsp) and submitted to the OAM Server: challenge_url = "http://host:port/externallogin.jsp" contextType="external" contextValue=Not applicable See Also: "About Custom Login Pages" and "Managing Global Password Policy"
Context Value	Used to build the final URL for the credential collector. The default value is /oam.

About Custom Login Pages

Only Schemes with the Challenge Method of FORM, X509, or DAP include additional elements described at the end of Table 16-19. All custom login pages must meet the following requirements:

• Custom login pages require two form fields (username and password). Access Manager supports custom forms as described in Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

• CustomWar and external context types, require logic within the custom login page to perform the following two tasks:

  • Send back the request ID the page received from the Access Manager server. For example: String reqId = request.getParameter("request_id"); <input type="hidden" name="request_id" value="<%=reqId%>">

  • Submit back to the OAM Server the end point, "/oam/server/auth_cred_submit". For example: <form action="/oam/server/auth_cred_submit"> or "http://oamserverhost:port/oam/server/auth_cred_submit".

For more information, see the following topics:

• Pre-configured Authentication Schemes

• About Challenge Methods

• About Challenge Parameters for Authentication Schemes

See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Access Management for details about customizing login pages and messages.

16.9.1.1 Pre-configured Authentication Schemes

Table 16-20 identifies the pre-configured authentication schemes available with Access Manager and some specific details of each. For more information about challenge parameters, see Table 16-20.

Table 16-20 Pre-configured Authentication Schemes

Scheme Name	Specifications	Purpose
AnonymousScheme	Authentication Level: 0 Challenge Method: None Authentication Module: AnonymousModule	Leaves unprotected specific Access Manager URLs and allows users to access such URLs without a challenge. Users are not challenged and do not need to enter their credentials. Note: Authentication Level 0 is for public pages. Oracle recommends that you do not use Level: 0 in a custom authentication scheme. Also: When a resource is protected by AnonymousScheme, it is not displayed in a session search.
BasicFAScheme Only for Oracle Fusion Applications	For Fusion Applications	For specific information about this authentication scheme, refer to the Oracle Fusion Applications Technology Library located on the Oracle Technology Network (OTN) web site: http://www.oracle.com/technetwork
BasicScheme	Authentication Level: 1 Challenge Method: Basic Authentication Module: LDAP	Protects Access Manager-related resources (URLs) for most directory types. Note: Authentication Level 1 is only one step higher than 0 public pages. Oracle recommends that you do not use Level: 1 in a custom authentication scheme.
BasicSessionlessScheme	Authentication Level: 1 Challenge Method: Basic Authentication Module: LDAP	Primarily used for clients that don't support URL redirect or cookies. Challenge Parameters: CookieLessMode=true Note: Authentication Level 1 is only one step higher than 0 public pages. Oracle recommends that you do not use Level: 1 in a custom authentication scheme.
FAAuthScheme Only for Oracle Fusion Applications	Authentication Level: 2 Challenge Method: FORM Authentication Module: LDAP Context: customWar Context Value: /fusion_apps	For specific information about this authentication scheme, refer to the Oracle Fusion Applications Technology Library located on the Oracle Technology Network (OTN) web site: http://www.oracle.com/technetwork
FederationMTScheme Only for Oracle Fusion Applications	Authentication Level: 2 Challenge Method: FORM Authentication Module: FederationMTPlugin Context Type: customWar Context Value: /fusion_apps Challenge Parameters: initial_command=NONE is_rsa=true	For specific information about this authentication scheme, refer to the Oracle Fusion Applications Technology Library located on the Oracle Technology Network (OTN) web site: http://www.oracle.com/technetwork See Also: "About Challenge Parameters for Authentication Schemes".
FederationScheme Only for Identity Federation 11.1.2.	Authentication Level: 2 Challenge Method: FORM Authentication Module: FederationPlugin Context Type: customWar Context Value: /oam Challenge Parameters: initial_command=NONE is_rsa=true	See Also: Part VII, "Managing Oracle Access Management Identity Federation". Note: With Oracle Identity Federation 11.1.1, use OIFScheme as described in the Oracle Fusion Middleware Integration Guide for Oracle Access Manager.
KerberosScheme	Authentication Level: 2 Challenge Method: WNA Authentication Module: Kerberos Context Type: customWar Context Value: /fusion_apps	Protects Access Manager-related resources (URLs) for most directory types based on a Windows Native Authentication challenge method and valid WNA credentials in Active Directory.
LDAPNoPasswordValidationScheme	Authentication Level: 2 Challenge Method: FORM Authentication Module: LDAPNoPasswordAuthModule Context Type: default Context Value: /oam Note: LDAPNoPasswordAuthModule is similar to the DAP (asserter) mechanism. See Also OAM10gScheme, later in this table.	Protects Access Manager-related resources (URLs) for most directory types based on a form challenge method. Used with the Identity Asserter for SSO when you have resources in a WebLogic Container. For details, see the Oracle Fusion Middleware Application Security Guide.
LDAPScheme	Authentication Level: 2 Challenge Method: FORM Authentication Module: LDAP Context Type: customWar Context Value: /fusion_apps	Protects Access Manager-related resources (URLs) for most directory types based on a form challenge method.
OAAMAdvanced	Authentication Level: 2 Challenge Method: FORM Authentication Module: LDAP Context Type: external	Protects OAAM-related resources with an external context type. This authentication scheme is used when complete integration with OAAM is required. A Webgate must front ending the partner.
OAAMBasic	Authentication Level: 2 Challenge Method: FORM Authentication Module: LDAP Context Type: default Context Value: /oam Challenge Parameters oaamPostAuth=true oaamPreAuth=true	Protects OAAM-related resources with a default context type. This scheme should be used when basic integration with OAAM is required. Here, advanced features like OTP are not supported. This is more of an integration when mod_osso is used as the agent.
OAM10gScheme	Authentication Level: 2 Challenge Method: OAM10G Authentication Module: LDAPNoPasswordAuthModule See Also LDAPNoPasswordValidationScheme, earlier in this table. enableCoexistMode and disableCoexistMode in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.	Facilitates integration and coexistence with Oracle Access Manager 10g. In the coexistence mode, Oracle Access Manager 10g is the authenticator and Access Manager 11g is the asserter. This scheme requires challenge mechanism OAM10G, specifically for OAM10g coexistence with OSSO as described in "OAM10G".
OAMAdminConsoleScheme	Authentication Level: 2 Challenge Method: FORM Authentication Module: LDAP Context Type: default Context Value: /oam	Authentication scheme for Oracle Access Management Console.
OICScheme	Authentication Level: 2 Challenge Method: DAP Authentication Module: TAPModule Context Type: External Challenge Parameters: TAPPartnerId=RPPartner MatchLDAPAttribute=mail	Access Manager uses this scheme to delegate authentication to Mobile and Social services and redirects the user to the Mobile and Social login page for authentication. See Also: Part IX, "Managing Oracle Access Management Mobile and Social"
OIFScheme Only for Oracle Identity Federation 11.1.1. For Identity Federation 11.1.2, use FederationScheme.	Authentication Level: 2 Challenge Method: DAP Authentication Module: DAP Context Type: External	This scheme delegates authentication to OIF, after which, Oracle Identity Federation sends back a token that is asserted by the OAM Server as described in the Oracle Fusion Middleware Integration Guide for Oracle Access Manager. The Delegated Authentication Protocol (DAP) challenge method is used to delegate authentication to a third-party (OIF in this case). Challenge Parameters: TAPPartnerId=OIFDAPPartner See Also: "About Challenge Parameters for Authentication Schemes".
OIMScheme	Authentication Level: 1 Challenge Method: FORM Authentication Module: LDAP Context Type: default Context Value: /oam	Protects Oracle Identity Manager-related resources with a default context type. Note: When integrating OAM and OIM, OAM downgrades the user's authentication level when any of the following is detected: password expiry forced password change challenge setup not done This enables the user to access the pages only after performing necessary operations in the identity management (OIM) page to which the user is redirected. At Level 1, only public and OIM pages for the required operations can be accessed. Note: Authentication Level 1 is only one step higher than 0 public pages. Oracle recommends that you do not use Level: 1 in a custom authentication scheme.
OSSOCoexistMigrateScheme		Set as the Default authentication scheme for environments that have been migrated from OSSO 10g to Access Manager 11g. See Also: Oracle Fusion Middleware Update, Upgrade, and Migration Guide for Oracle Identity and Access Management.
PasswordPolicyValidationScheme	Authentication Level: 2 Challenge Method: FORM Authentication Module: Password Policy Validation Module Context: External	Enables password policy evaluation.
TAPResponseOnlyScheme	Authentication Level: 2 Challenge Method: DAP Authentication Module: DAP
TAPScheme	Authentication Level: 2 Challenge Method: DAP Authentication Module: DAP Context Type: External	To use TAPScheme for IDM product resources in the IAM Suite Application Domain, Protected HigherLevel Policy, the following configuration must be done in addition to changing the Authentication Scheme. From the IAM Suite Application Domain, Protected Higher Level Policy, remove IAMSuiteAgent:/oamTAPAuthenticate. Create a new Authentication Policy in the IAM Suite Application Domain, that uses LDAPScheme. Protect IAMSuiteAgent:/oamTAPAuthenticate using the newly created policy. Challenge Parameters: TAPPartnerId=TAPPartnerName
X509Scheme	Authentication Level: 5 Challenge Method: X509 Authentication Module: X509	This authentication scheme is a certificate-based user identification method. To use this method, a certificate must be installed on the user's browser and the Web server must be SSL-enabled. Note: This scheme relies on SSL to deliver the use's X.509 certificate to the OAM Server.

16.9.1.2 About Challenge Methods

Authentication involves determining what credentials a user must supply when requesting access to a resource, gathering credentials over HTTP, and returning an HTTP response that is based on the results of credential validation. Access Manager provides the following credential challenge methods for use in an authentication scheme:

• FORM

• BASIC

• X509

• WNA

• NONE

• DAP

• OAM10G

FORM

This authentication challenge uses an HTML form with one or more text input fields for user credentials. In a typical form-based challenge, users enter a user name and password in two text boxes on the form. The most common credential choices are user name and password; however, you can use any user attributes: for example, user name, password, and domain.

A Submit button posts the content of the form. When the user clicks the Submit button, the form data is posted to the Web server. OAM and OSSO Agents intercept and process the form data. Upon validation of the user credentials collected in the form, the user is authenticated.

Note:

This challenge method relies on an LDAP Authentication Module and the user identity store associated with that module.

You might want to use form-based authentication challenge for reasons such as:

• A consistent user experience: Using form-based login and a standardized logout means that the user experience for login and logout features will be consistent across browsers.

• A Custom Form: You can apply your organization's look and feel in the authentication process.

  For example, a custom form can include a company logo and a welcome message instead of the standard user name and password window used in Basic authentication.

• Additional Information: You can gather additional information at the time of login.

• Additional Functionality: You can provide additional functionality with the login procedure, such as a link to a page for lost password management.

BASIC

This built-in Web server challenge mechanism requires a user to enter her login ID and password. The credentials supplied are compared to the user's definition in the LDAP directory server.

Note:

A Basic challenge relies on an LDAP Authentication Module and the user identity store associated with that module.

X509

With the X509 certificate challenge method, a user's browser must supply an X.509 digital certificate over SSL to the OAM Server through the Agent to perform authentication.

Note:

X509 is the challenge method for the X509Scheme. The user's organization can determine how to obtain a certificate.

The X.509 client certificate must be verified against the trusted CAs in the keystore used by OAM Proxy and OAM Servers to ensure the validity of X.509 Client certificate for authentication.

The following attributes of the X.509 certificate can be validated against the user identity store associated with Access Manager:

• SubjectDN

• SubjectUniqueID

• Mail

• CN

To acquire the user entry, the X509 Authentication Module takes the attribute name of the X.509 certificate to be validated and the LDAP attribute against which the search will be launched. The expected result is the single user entry matching the criteria. If the search returns no user entry, or more than one entry, authentication fails. Authentication scheme parameters are located in oam-policy.xml.

Note:

For X509 authentication, Administrators must configure the Oracle HTTP Server as a reverse proxy (or a server with the wl-proxy plug-in). The Oracle HTTP Server must be configured in two way SSL Mode to acquire X.509 certificate for authentication. Oracle HTTP Server can also be configured for CRL verification.

The online certificate status protocol (OCSP) capabilities are also provided. Any certificate passed for X.509 certificate-based authentication is validated using an OCSP request. Administrators can configure the system to communicate with one or more OCSP servers to retrieve the certificate status.

The X509 Authentication Module configuration for the OCSP responder URL indicates whether OCSP validation is to be done. The value, if specified, indicates the URL for validation of the X.509 client certificate using OCSP. No value indicates no OCSP validation.

WNA

Uses Windows Native Authentication with Active Directory, and the Kerberos Authentication Module.

Note:

The KerbScheme relies on the WNA challenge method and Kerberos Authentication Module.

See Also:

Chapter 43 for details about integration with Windows Native Authentication

NONE

The challenge method of None means that users are not challenged and do not need to enter their credentials. This is used in the AnonymousScheme authentication scheme, which allows users to access Access Manager-specific URLs that you do not want to protect.

DAP

The Delegated Authentication Protocol (DAP) challenge method is required for OIFScheme (Oracle Identity Federation 11.1.1 integration) with the DAP authentication module and external context type (Table 16-19). The DAP challenge mechanism indicates that Access Manager does an assertion of the token that it receives, which differs from the standard challenge "FORM" mechanism with the external option.

DAPModule is an assertion module, though it is specialized for this one application and does not appear in the list of Authentication Modules in the Oracle Access Management Console. This integration replaces OSSO 10g with Access Manager 11g, with no changes from the Identity Federation side.

The DAP challenge mechanism delegates authentication to a third party (Identity Federation in this case). The challenge_url points to the Identity Federation Server URL. When a resource is protected by this scheme, the OAM Server redirects to the Identity Federation Server URL for credential collection. OAM Server does not perform the credential collection or validation in this case. Identity Federation collects the credentials, authenticates the user against its identity store and returns an assertion token to the OAM Server consisting of the username. Access Manager receives and decrypts this token, checks whether the user is a valid user in the default identity store for Oracle Access Management. If the user is valid, Access Manager gives access to the resource.

The DAPToken is encrypted and decrypted with a key that is shared between Access Manager and Identity Federation. The DAPToken is built from the Access Manager side.

The Identity Federation Administration EM Console provides a way to generate the keystore containing the encryption keys that will be used to secure communications between the Access Manager and Identity Federation. Access Manager provides a WLST command (registerOIFDAPPartner), that takes the keystore location generated by the Identity Federation store and retrieves the keys and stores it on the Identity Federation side.

OAM10G

This mechanism is created for Oracle Access Manager 10g coexistence with OSSO 10g. The OAM10G method always acts as the authentication and authorization provider and is required for OAM10gScheme with the LDAPNoPasswordAuthModule to facilitate trust when you have Oracle Access Manager 10g protecting a domain that also includes an OSSO 10g integrated classic application (Portal, Disco, and so on).

OSSO10g is protected with OAM10G challenge method through Webgate; OAM10G always acts as the authentication and authorization provider.

Facilitating Integration: The OSSO 10g integrated classic applications can be upgraded to Access Manager, which then acts only as an asserter. Access Manager creates the tokens that mod_osso can consume so that access can be provided to these applications. The mod_osso applications are protected by the new "OAM10gScheme". There is a Webgate front ending the OAM Server and configured against the 10g Access Server.

Setup: When the resource is accessed, Webgate intercepts the request and sends it to the 10g Access Server for authentication. Oracle Access Manager 10g collects the credentials, validates it against its identity store, and sets the username as a header variable (OAM_REMOTE_USER). The request now goes to the OAM Server which uses the OAM10gScheme to locate the username in the header variable. Access Manager retrieves the header variable and asserts the presence of the user against the primary identity store. If present, the required cookies (OAM_ID) are generated and redirected to the resource.

See Also:

• OAM10gScheme in Table 16-20

• enableCoexistMode and disableCoexistMode in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference

16.9.1.3 About Challenge Parameters for Authentication Schemes

Challenge parameters are short text strings consumed and interpreted by Webgates and Credential Collector modules to operate in the manner indicated by those values.

The syntax for specifying any challenge parameter is:

<parmatername>=<value>

This syntax is not specific to any Webgate release (10g versus 11g). Authentication schemes are independent of Webgate release.

Table 16-21 identifies the pre-configured schemes with challenge parameters.

Table 16-21 Challenge Parameters in Pre-configured Schemes

Pre-configured Schemes	Challenge Parameter
BasicSessionlessScheme	CookieLessMode=true Primarily used for clients that do not support URL redirect or cookies.
FederationMTScheme	initial_command=NONE Primarily used for Fusion Applications that support multiple factor authentication. is_rsa=true Used with RSA multi-step authentication, as described in Chapter 42, "Integrating RSA SecurID Authentication with Access Manager" and the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.
FederationScheme For Identity Federation 11.1.2.only. Use OIFScheme for Oracle Identify Federation 11.1.1.	Primarily used for clients that do not support URL redirect or cookies. Context Value: /fusion_apps Challenge Parameters: initial_command=NONE is_rsa=true Primarily used for clients that do not support URL redirect or cookies.
OAAMBasic	oaamPostAuth=true oaamPreAuth=true Protects OAAM-related resources. These parameters should be used when basic integration with OAAM is required.
OIFScheme For Oracle Identify Federation 11.1.1 only. Use FederationScheme for Identity Federation 11.1.2.	TAPPartnerId=OIFDAPPartner This scheme delegates authentication to Oracle Identity Federation 11.1.1, after which, Federation sends back a token that is asserted by the OAM Server.
TapScheme	TAPPartnerId=TAPPartnerName

An authentication scheme can collect context-specific information before submitting the request to the Access Server. Context-specific information can be in the form of an external call for information. Table 16-22 lists user-defined challenge parameters you can use in Authentication Schemes.

Table 16-22 User-Defined Challenge Parameters for Authentication Schemes

Challenge Parameter	Definition
initial_command=NONE	Required to enable the plug-in to indicate which credentials are to be collected. For example, for Form-based authentication, the framework typically expects to collect "username" and "password" (submitted from the login page). However, you might want credentials from different fields of the login page; "form_username" and "form_password" for example. Setting this challenge parameter shifts initial control from the login page to the plug-in, which decides the parameters to collect from the login page then appropriately forwards or redirects to the page. Default: blank (not set)
action=	The actions parameter identifies the URL to which the HTML form is posting when you do not want to use the hard coded ECC default /oam/server/auth_cred_submit. Note: ECC does not use the action= parameter. When the action= challenge parameter is not specified, both the DCC and ECC use the default: /oam/server/auth_cred_submit. See Also: "Configuring the PasswordPolicyValidationScheme"
creds= DCC Only	Supported by the detached credential collector (DCC) only. In the following example, username and password are the names of relevant fields in the login form: creds=username password Here is another example: creds:source$name where source refers to one of the following (if omitted, sources are searched in the following order): server (variables set by other Web server plug-ins) header (HTTP header variables) post (posted data) query (query string data) cookie (HTTP cookie) The Web server source (server parameter) takes precedence over other sources. This prevents the request data, which is under control of the user, from overriding Web server data. For example, a remote_user cookie sent from a user will not override a remote_user variable set by the Web server Generally, when the user submits a login form that is protected by an authentication scheme with a Form-based challenge method, the DCC processes the credentials that were specified with this creds= parameter. For forms using METHOD=POST processing, the browser sends a POST request to the Web server with the credential data from the form in the body of the request. If the form uses METHOD=GET, the browser sends a GET request with query string parameters with the same names as those specified on the creds parameter. Oracle recommends that you use POST processing, if possible. Note: You can specify the creds parameter with the other types of challenge methods. For a plug-in to make use of the creds parameter, you specify what is passed in the obMap credentials parameter of the ObUserSession object, as described in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management. See Also: "Configuring the PasswordPolicyValidationScheme"
extracreds= DCC Only	Supported by the DCC only. Specifies optional parameters which, if present, are made available to the authentication plug-in for collection during each iteration of a multi-step authentication using the DCC. The extracreds parameter uses the same syntax as the creds parameter: extracreds= separated qualified or unqualified names [{any | cookie | header | server | query | post}:] <name>. However, the value any is used by extracreds only. For example: extracreds=[{any | cookie | header | server | query | post}:] <name> See Also: "Configuring the PasswordPolicyValidationScheme"
OverrideRetryLimit=0	The number of tries that can override the RetryLimit for login. The value must be a positive integer. A value of zero (0) disables this function. See Also: "Configuring the PasswordPolicyValidationScheme"
MaxPostDataBytes=	Restricts the maximum number of bytes of POST data that is submitted as user credentials and sent to the OAM Server. See Also: "Configuring the PasswordPolicyValidationScheme"
ssoCookie=	Controls the OAMAuthnCookie cookie, as described in "Configuring Challenge Parameters for Encrypted Cookies". Default: ssoCookie=httponly ssoCookie=Secure Disable either setting: ssoCookie=disablehttponly ssoCookie=disableSecure Note: These parameters are configured differently depending on your credential collector configuration. For detached credential collector-enabled 11g Webgates, set these parameters directly in the agent registration page. For non-DCC agents (Resource Webgates), these parameters are configured through user-defined challenge parameters in authentication schemes. See Also: Table 16-23, "Challenge Parameters for 10g/11g Encrypted Cookies"
miscCookies=	Controls other miscellaneous Access Manager internal cookies. By default, httponly is enabled for all other (miscellaneous) cookies. Default: miscCookies=httponly miscCookies=Secure Disable either setting: miscCookies=disablehttponly miscCookies=disableSecure Note: These parameters are configured differently depending on your credential collector configuration. For detached credential collector-enabled Webgates, set these parameters directly in the agent registration page. For non-DCC agents (Resource Webgates), these parameters are configured through challenge parameters of the same name. See Also: Table 16-23, "Challenge Parameters for 10g/11g Encrypted Cookies" "Configuring the PasswordPolicyValidationScheme"
DCCCtxCookieMaxLength= DCC Only	Defines the maximum length of the DCC cookie. Default: 4096 See Also: TempStateMode in this table for more information.
TempStateMode=	Controls how the DCC stores the OAM Server state (cookie or form) as specified with the parameter's value: form: This is the default. OAM Server state stored and passed through the form parameter "OAM_REQ", to avoid the case when the OAM Server configuration serverRequestCacheType=COOKIE, bloated server state causes DCCCtxCookie to explode beyond limit resulting in incorrect behavior. The cookie cache mode can be changed to FORM mode from default COOKIE mode. FORM mode works with long URLs. The only difference in behavior is for programmatic authentication, which requires a proper form Submit to pass the OAM_REQ parameter set to the form. Custom credential collection pages need to handle the OAM_REQ parameter that is submitted with the form. cookie: Adding this parameter and value stores the OAM Server state through part of the DCCCtxCookie (encdata=… svrctx=…). However, when serverRequestCacheType=COOKIE or =FORM, this could cause incorrect behavior if the resulting cookie length is beyond browser limit. Note: When serverRequestCacheType=COOKIE, Oracle recommends TempStateMode=form. When serverRequestCacheType=BASIC, either mode is fine. To update serverRequestCacheType, use the WLST command configRequestCacheType as described in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference. Editing serverRequestCacheType is not supported using the Oracle Access Management Console. With ECC: The serverRequestCacheType dictates whether OAM Server stores its state in memory(BASIC) or not (FORM or COOKIE). serverRequestCacheType = COOKIE or FORM only makes difference when ECC is used. OAM Server stores its state in a request token, which ECC keeps in a cookie or hidden form field as specified with the parameter: serverRequestCacheType=COOKIE, for example. With DCC: There is no difference between serverRequestCacheType=COOKIE or FORM. TempStateMode controls how the DCC stores the OAM Server state (cookie or form) as specified with the parameter's value: TempStateMode=cookie, for example. See Also: "Configuring 11g Webgate and Authentication Policy for DCC" Table 13-2, "User-Defined Webgate Parameters"

16.9.2 Understanding Multi-Level and Step-Up Authentication

This section provides the following topics:

• About Multi-Level and Step-Up Authentication

• Detection of Insufficient Authentication Level by OAM Agent

• Multi-Level Authentication Processing with 10g OSSO Agent

16.9.2.1 About Multi-Level and Step-Up Authentication

Every authentication scheme requires a strength level. The lower this number, the less stringent the scheme. A higher level number indicates a more secure authentication mechanism:

• LDAPScheme authLevel=1

• KerbScheme authLevel=2

Note:

Multi-level authentication does not affect, negate, or alter X.509 certificate authentication.

SSO capability enables users to access more than one protected resource or application with a single sign in. After a successful user authentication at a specific level, the user can access one or more resources protected by one or more Application Domains. However, the authentication schemes used by the Application Domains must be at the same level (or lower). When a user accesses a resource protected with an authentication level that is greater than the level of his current SSO token, he is re-authenticated. In the step-up case, the user maintains his current level of access even if failing the challenge presented for the higher level. This is "additional authentication".

Note:

A user who is authenticated to access resources at level 3, is eligible to access resources protected at levels less than or equal to 3. However, if the user is authenticated to access resources at level 2 and then attempts to access resources protected by level 3, the user is asked to re-authenticate (this is known as step-up authentication).

Access Manager policies allow different resources of the same application to be protected with different authentication levels. However, the mod_osso plug-in does not support two resources on the same application with a different trust level.

Note:

mod_osso delegates authentication to Access Manager. Oracle recommends that mod_osso-protected resources be protected with Access Manager authentication levels.

In such cases, the application must enforce the Level and send the Dynamic Directive to mod_osso for re-authentication. On receiving the Dynamic Directive, mod_osso will redirect to Access Manager for re-authentication at the appropriate level.

Both agent types redirect the user to the OAM Server to authenticate again. The challenge is presented according to the level of the authentication scheme configured in the policy for the resource.

Registered agents detect the authentication level as follows:

• OAM Agents receive an insufficient level error message from the OAM Server, as described in "Detection of Insufficient Authentication Level by OAM Agent"

• mod_osso detects the authentication level from dynamic directives, as described in Multi-Level Authentication Processing with 10g OSSO Agent

See Also:

Oracle Fusion Middleware Integration Guide for Oracle Identity Management Suite chapter Integrating Access Manager and Oracle Adaptive Access Manager for an example. The user was already authenticated when he accessed another resource with a lower authentication level using Access Manager. Oracle Adaptive Access Manager does not show the user name and password pages because the user is already authenticated. However, the flows that are executed in Oracle Adaptive Access Manager depend on whether the user was already logged in to Oracle Adaptive Access Manager.

16.9.2.2 Detection of Insufficient Authentication Level by OAM Agent

When the user requests a resource that is protected with a higher level authentication scheme, the following process occurs.

Process overview: OAM Agent detects insufficient session level

No check of the authentication level is made on the server side. The following example refers to a 10g OAM Agent.

Note:

11g OAM Agents are associated with individual per-agent OAMAuthnCookies.

1. The OAM Agent sends the request to the OAM Proxy to obtain the scheme details for the protected resource.

2. The OAM Agent sends the request for session information to the OAM Proxy.

3. The OAM Proxy returns details of the ObSSOCookie, including the authenticated level of the ObSSOCookie.

4. The OAM Agent compares the level of ObSSOCookie with that of the authentication scheme.

   • If insufficient, the agent invokes the authentication process again.

   • If sufficient, the access is granted access.

16.9.2.3 Multi-Level Authentication Processing with 10g OSSO Agent

In contrast to OAM Agents, all the resources protected by mod_osso on a host (or virtual host) are protected at the same level.

With mod_osso, multi-level authentication applies when user is already authenticated using one mod_osso host (or virtual host) at Level 2 and then tries to access another mod_osso protected host (or virtual host) at level 3.

Process overview: OSSO Agent multi-level authentication flow

1. The user tries to access a resource protected by mod_osso on host1 at level 2.

2. The OSSO Agent sends the request to the OAM Proxy to obtain the authentication scheme details for the protected resource.

3. The OAM_ID cookie for SSO Server and a host based cookie "HOST_port" for host1 are set and contain authentication level information.

4. After authentication, the user tries to access a resource on host2 that is protected with a higher level of authentication.

5. The user is redirected to the OAM Server for authentication because this is the first time accessing host2.

6. The OAM Server (OSSO Proxy) receives the OAM_ID cookie which has an insufficient level to access the resource on host2.

   • If the level is insufficient, the OAM Server (OSSO Proxy) triggers re-authentication.

   • If the level is sufficient, the access is granted access.

16.9.3 Creating an Authentication Scheme

Users with valid Administrator credentials can use the following procedure to add a new authentication scheme for use in an Application Domain.

Prerequisites

The authentication module must be defined and ready to use as described in "Deploying and Managing Individual Plug-ins for Authentication".

See Also:

• "About Authentication Schemes and Pages"

• "Adding PasswordPolicyValidationScheme to Authentication Policy for DCC" if needed

To create an authentication scheme

1. From the Oracle Access Management Console, go to the:

   
   Policy Configuration tab
   Shared Components node
   Authentication Schemes node
   

2. Click Authentication Schemes, then click the Create button in the tool bar.

3. Fill in the fresh Authentication Scheme page (Table 16-19) by supplying information based on your deployment:

   1. Name: LDAPSimpleFormScheme

   2. Authentication Level

   3. Challenge Method: FORM

   4. Challenge Redirect URL: http://CredentialCollectorhost:port

   5. Authentication Module: LDAP

   6. Challenge URL: /CredentialCollector/loginform...

   7. Challenge Parameters: Table 16-21, Table 16-22, Table 16-23

   8. Context Type

4. Click Apply to submit the new scheme (or close the page without applying changes).

5. Dismiss the Confirmation window.

6. Optional: Click the Set as Default button to automatically use this with new Application Domains, then close the Confirmation window.

7. In the navigation tree, confirm the new scheme is listed (Refresh the tree, if needed).

8. Proceed to "Defining Authentication Policies for Specific Resources".

16.9.4 Searching for an Authentication Scheme

Users with valid Administrator credentials can perform the following task to search for a specific authentication scheme.

See Also:

"Conducting Searches Using the Console"

To search for an authentication scheme

1. Activate the Policy Configuration tab, and then click the Search tab.

2. From the search type list, choose Authentication Schemes to define your search.

3. In the text field, enter the desired scheme name (with or without wild card *). For example:

   OA*
   

4. Click the Search button to initiate the search.

5. Click the Search Results tab to display the results table, and then:

   • Edit: Click the Edit button in the tool bar to display the configuration page.

   • Delete: Click the Delete button in the tool bar to remove the instance; confirm removal in the Confirmation window.

   • Detach: Click Detach in the tool bar to expand the table to a full page.

   • View: Select a View menu item to alter the appearance of the results table.

6. Click the Browse tab to return to the navigation tree when you finish with the Search results.

16.9.5 Viewing, Editing, or Deleting an Authentication Scheme

Users with valid Administrator credentials can use the following procedure to view or modify an existing authentication scheme.

Note:

During a delete operation, if the Authentication Scheme is associated with any authentication policy, she is prompted with association details. Without policy associations, the scheme is deleted.

See Also:

• "About Authentication Schemes and Pages"

• "Configuring the PasswordPolicyValidationScheme"

To view or modify an authentication scheme

1. From the Oracle Access Management Console, open the desired scheme:

   
   Policy Configuration tab
   Shared Components node
   Authentication Schemes node
   DesiredScheme
   

2. Edit:

   1. On the Authentication Scheme page, modify values for your environment (Table 16-19).

      Note:

      In an upgraded deployment with OSSO Agents, change the Authentication Scheme and any Protected Resource Policies to use SSOCoExistMigrateScheme.

   2. Click Apply to submit the changes (or close the page without applying changes).

   3. Dismiss the Confirmation window.

3. Set as Default: Click the Set as Default button to automatically use this scheme when creating policies in fresh Application Domains, then close the Confirmation window.

4. Delete:

   1. Review any Application Domain using this authentication scheme and assign a different scheme.

   2. Review the Authentication Scheme page to confirm this is the scheme to remove, then close the page.

   3. In the navigation tree, click the name of the scheme and then click the Delete button in the tool bar.

   4. Confirm removal (or dismiss the Confirmation window).

16.10 Configuring Challenge Parameters for Encrypted Cookies

This section provides the following topics:

• About Challenge Parameters for Encrypted Cookies

• Configuring Challenge Parameters for Security of Encrypted Cookies

• Setting Challenge Parameters for Persistence of Encrypted Cookies

16.10.1 About Challenge Parameters for Encrypted Cookies

In addition to the OAM Server cookie (OAM_ID), Access Manager implements single sign-on through an encrypted cookie:

• 11g Webgate, One per agent: OAMAuthnCookie_<host:port>_<random number> set by Webgate using the authentication token received from the OAM Server after successful authentication

  Note: A valid OAMAuthnCookie is required for a session.

• 10g Webgate, One ObSSOCookie for all 10g Webgates.

Access Manager provides the ssoCookie challenge parameter that you can use within any authentication scheme to control how Webgates set the flags of the encrypted cookie. For example:

• Securing Encrypted Cookie: Ensures that the encrypted cookie is sent only over an SSL connection and prevents the encrypted cookie from being sent back to a non-secure Web server.

• Persisting Encrypted Cookie: Allows the user to log in for a time period rather than a single session. Persistent cookie functionality works with Internet Explorer and Mozilla browsers.

Note:

The value of the challenge parameter is note case sensitive. Syntax is the same regardless of your Webgate release. A single value is specified after the equal sign (=):

ssoCookie=value

Multiple values must be separated by a semicolon (;). For example:

ssoCookie=value1;value2;...

• For detached credential collector-enabled Webgates, set these parameters directly in the agent registration page (Table 13-2).

• For non-DCC agents (Resource Webgates), these parameters are configured through Authentication Scheme challenge parameters (Table 16-23).

Table 16-23 describes specific challenge parameters that control how Webgates set encrypted cookie flags for single sign-on.

Table 16-23 Challenge Parameters for 10g/11g Encrypted Cookies

11g /10g Webgate Challenge Parameter Syntax for Encrypted Cookies	Description
ssoCookie=	Parameter that controls flags for the SSO cookie OAMAuthnCookie.
miscCookies=	Parameter that controls flags for all other Access Manager encrypted cookies.
Secure	Ensures that the encrypted cookie is sent only when the resource is accessed through HTTPS. A secure cookie is required only when a browser is visiting a server using HTTPS. ssoCookie=Secure miscCookies=Secure
disableSecure	Explicitly disables Secure cookies. ssoCookie=disableSecure miscCookies=disableSecure
httponly	Enabled by default with 11g Webgate SSO OAMAuthnCookie and miscellaneous cookies. ssoCookie=httponly miscCookies=httponly
disablehttponly	Explicitly disables httponly functionality, making the encrypted cookies accessible to client-side scripts. ssoCookie=disablehttponly miscCookies=disablehttponly
ssoCookie=max-age=time-in-seconds	Creates a persistent cookie in browsers, rather than one that lasts for a single session, and specifies the time interval in-seconds when the cookie expires. For example, to set the cookie to expire in 30 days (2592000 seconds): max-age=2592000

16.10.2 Configuring Challenge Parameters for Security of Encrypted Cookies

The challenge parameter is not case sensitive.

See Also:

"Creating an Authentication Scheme"

To secure the encrypted cookie

1. Create an authentication scheme.

2. In the Challenge Parameter field, enter your specification for the desired encrypted cookies (Table 16-23).

3. Confirm that the OAM Servers and clients (OAM Agents) are communicating securely across the Oracle Access Protocol channel, as described in Appendix C.

16.10.3 Setting Challenge Parameters for Persistence of Encrypted Cookies

The challenge parameter is not case sensitive.

See Also:

"Creating an Authentication Scheme"

To define encrypted cookie persistence

1. Define an authentication scheme.

2. In the challenge parameter for this scheme, add the following (Table 16-23):

   Webgate ssoCookie=max-age=time-in-seconds

16.11 Understanding Password Policy

This section provides the following topics:

• Previewing Oracle-Provided Password Forms and Functionality

• Previewing the Password Policy Page in Oracle Access Management Console

• About Credential Collectors and Password Policy Validation

16.11.1 Previewing Oracle-Provided Password Forms and Functionality

Access Manager provides several pages for user interactions during credential collection, as described in Credential Collector Password Pages. The location can be customized, depending on the desired topology of the authentication scheme being developed.

Table 16-24 Credential Collector Password Pages

Credential Collector	Description
ECC pages	The default embedded credential collector jsp forms, by default, reside on the OAM Servers. Login page: /pages/login.jsp Logout page: /pages/logout.jsp Error page: /pages/servererror.jsp Multi-step authentication page: /pages/mfa.jsp
DCC pages	Dynamic pages general login/logout and password policy with the DCC are excluded automatically through the OHS httpd.conf/webgate.conf file--you do not need to configure a policy to exclude these. See the Webgate host: WEBGATE_HOME/webgate/ohs/oamsso/* WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl (update the Perl location in the first line of the login, logout, and securid scripts) WEBGATE_HOME/webgate/ohs/oamsso-bin/templates/* See Also: For details about customizing pages and messages, see the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

Table 16-25 shows the password forms provided.The default pages can be customized for your enterprise, or replaced entirely with custom pages. For example, you can design, implement, and deploy a custom page that displays a different version of the login form for a mobile browser than is used for a desktop browser.

Table 16-25 Password Management Forms and Functions

Form	Function
Sign In Form	The standard login form provides fields for userID and password. Clicking the Login button initiates authentication processing governed by the authentication module. See: Oracle Fusion Middleware Developer's Guide for Oracle Access Management for details about customizing login forms.
Sign In Error	This standard login form appears when an error occurs. The text in red identifies the errors, which can be suppressed or displayed. See: Oracle Fusion Middleware Developer's Guide for Oracle Access Management for details about suppressing or displaying.
Password Expiry Notification	The following message appears to inform the user that her password will expire, based on the notification policy.
Change Password Form	Based on password expiration policy configuration, the following window appears to enforce the policy and require user to change his password.
Password Change Success	The following message appears to confirm the password change was successful.
Locked or Disabled User Account	Based on the password policy, user account lockout occurs when supplied credentials fail during the maximum allowed login attempts.

16.11.2 Previewing the Password Policy Page in Oracle Access Management Console

Figure 16-28 shows the Password Policy page in the Oracle Access Management Console. Administrators use this page to define policy based on enterprise requirements.

Figure 16-28 Password Policy Configuration Page

Table 16-26 describes configurable password policy elements (as read from left to right in the console).These elements are used by both the ECC and DCC.

Table 16-26 Password Policy Elements

Element	Description
Minimum Uppercase Characters	Defines the minimum number of uppercase characters required in a password.
Minimum Lowercase Characters	Sets the minimum number of lowercase characters required in a password.
Minimum Alphabetic Characters	Defines the minimum number of special characters allowed in the password.
Minimum Numeric Characters	Sets the minimum number of numeric characters required in a password.
Minimum Alphanumeric Characters	Defines the minimum number of alphanumeric characters required in a password.
Minimum Special Characters	Sets the minimum number of special characters required in a password.
Maximum Special Characters	Defines the maximum number of special characters allowed in a password.
Minimum Unicode Characters	Defines the minimum number of unicode characters required in a password.
Maximum Unicode Characters	Sets the maximum number of unicode characters allowed in a password.
Minimum Password Length	Sets the total minimum number of characters required in a password.
Maximum Password Length	Defines the total maximum number of characters allowed in a password.
Characters Required	Defines the specific characters that are required in a password. No delimiter is needed or allowed in this definition.
Characters Not Allowed	Sets the specific characters that cannot be used in a password. No delimiter is needed or allowed in this definition
Characters Allowed	Defines all allowed characters in a password. No delimiter is needed or allowed in this definition
Substrings Not Allowed	Specific character strings that are not allowed in a password. Use a comma as the delimiter in this definition.
Start with alphabet	Specifies that the first character in a password must be alphabetic, when checked.
Allow last name	Specifies that the user's last name is allowed in the password, when checked.
Allow first name	Specifies that the user's first name is allowed in the password, when checked.
Allow User ID	Specifies that the user's userID is allowed in the password, when checked.
Warn after	Defines when (in days) to warn a user before her password will expire.
Maximum Attempts	Identifies the maximum number of login attempts a user can make before a lockout.
Expire after	Defines the period of time (in days) that the password is valid.
Lockout Duration	Identifies the period of time the user is locked out (in minutes) after the designated number of failed login attempts. After this period, the user can attempt a fresh login.
Permanent Lockout	specifies permanent lockout after the designated number of failed login attempts.
Disallow Last	Defines the number of previous passwords that cannot be used when the user changes her password.
Password Dictionary File	Identifies the physical file on OAM Servers that contain the list of restricted words that can not be specified in a password.
Password File Delimiter	Defines the delimiter used in the Password Dictionary file to separate various words. For example, if the file contains abc,def,welcome and the dictionary delimiter is comma (,), the words that are restricted and cannot be used in a user password are abc def and welcome.
Password Service URL	The location of various password pages.

16.11.3 About Credential Collectors and Password Policy Validation

Regardless of the credential collection method you choose, you can configure one global password policy that applies to all Access Manager-protected resources (using the Password Policy Validation Module in the authentication scheme). Also, the relevant URLs for the credential collector and related forms must be specified as outlined in Table 16-27.

Table 16-27 Specifying Credential Collectors and Related Forms for Authentication

In the . . .	For the ECC . . .	For the DCC . . .
OAM Agent Registration DCC Only	N/A.	Check the box beside Allow Management Operations in the OAM Agent registration page. See Also: "Enabling DCC Credential Operations"
login, error, and password pages	Pages where the user enters credentials arrive out of the box on the OAM Server and require no additional settings or changes. Login page: /pages/login.jsp Logout page: /pages/logout.jsp Error page: /pages/servererror.jsp Multi-step authentication: /pages/mfa_login.jsp	Dynamic pages for general login/logout and password policy with the DCC are excluded automatically through the OHS httpd.conf/webgate.conf file--you do not need to configure a policy to exclude these. See Webgate host directories WEBGATE_HOME/webgate/ohs/oamsso/*, WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl, and WEBGATE_HOME/webgate/ohs/oamsso-bin/templates/* for: Login page: /oamsso-bin/login.pl Logout: /oamsso-bin/logout.pl RSA SecurID login pages: /oamsso-bin/securid.pl Perl Scripts for DCC-based Login and Logout The path name of the Perl executable must be updated in Oracle-provided Perl scripts on the Webgate host WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl to be consistent with the actual location. See Also: Table 16-5, "Comparing the DCC and ECC"
Password Policy, Password Service URL	The Default/ECC password page is used automatically: Password Service URL for ECC: /oam/pages/pswd.jsp See Also: "Defining Your Global Password Policy"	Enter the DCC password page: Password Service URL for DCC: /oamsso-bin/login.pl See Also: "Locating and Updating DCC Forms for Password Policy"
User Identity Store	The user data object definition in the Access Manager schema is extended with attributes that enable password user status and password history maintenance. This definition is provided in an LDIF file, and must be added to each user identity store using the ldapadd tool. Oracle-provided LDIFs are identified in Table 16-28.	Same for both DCC and ECC: See Also: "Adding Key Password Attributes to the Default Store" "Adding an Administrator to Change User Attributes After a Password Change"
Password Policy Validation Authentication Module	Enter the Default Store as the KEY_IDSTORE_REF for each of the three plug-ins / steps (with an Error redirect on Failure): See Also: Table 16-13, "Parameter Details for Various Plug-ins" "Configuring the Password Policy Validation Authentication Module"	Same for both DCC and ECC:
Authentication Scheme, Challenge Redirect URL	Enter the Credential Collector host: For ECC, relative URI format: /oam/server (server prepends the host:port) See Also: "Configuring the PasswordPolicyValidationScheme"	Enter the Credential Collector host: For DCC, full URL: http://dcchost:port For DCC combined with Resource Webgate: Leave empty See Also: "Configuring the PasswordPolicyValidationScheme"
Authentication Scheme, Challenge URL	Enter the Credential Collector login form relative URI: For ECC: /pages/login.jsp See Also: "Configuring the PasswordPolicyValidationScheme"	Enter the Credential Collector login form relative URI: For DCC: /oamsso-bin/login.pl See Also: "Configuring the PasswordPolicyValidationScheme"
Authentication Scheme, Challenge Parameters	ECC: User-defined Challenge Parameters: OverrideRetryLimit=0 initial_command=NONE See Also: Table 16-22, "User-Defined Challenge Parameters for Authentication Schemes" "Configuring the PasswordPolicyValidationScheme"	DCC: User-defined Challenge Parameters: creds extracreds MaxPostDataBytes DCCCtxCookieMaxLength TempStateMode See Also: Table 16-22, "User-Defined Challenge Parameters for Authentication Schemes" "Configuring the PasswordPolicyValidationScheme"
Server Error Mode	Same for both DCC and ECC. See: "Setting the Error Message Mode for Password Policy Messages"	Same for both DCC and ECC. See: "Setting the Error Message Mode for Password Policy Messages"
Authentication Policy	Credential collectors in authentication policies: ECC: Use any authentication scheme configured for the ECC in the application domain for the protecting Webgate (Resourcre Webgate) See Also: "Adding Your PasswordPolicyValidationScheme to ECC Authentication Policy"	Credential collectors in Authentication Policies: DCC Separate from Resource Webgate: ***Protecting (Resource) Webgate Application Domain, (Authentication Policy protecting resources), use the DCC-related Authentication Scheme. ***DCC Webgate Application Domain, Authentication Policy protecting resources, use the DCC-related Authentication Scheme. Consider: --With No Action URL: DCC uses thedefault /oam/server/auth_cred_submit, which is automatically protected with the DCC-related authentication scheme. --With an Action URL: Explicitly protect the specified Action URL with the DCC Scheme. See Also: "Adding PasswordPolicyValidationScheme to Authentication Policy for DCC"
Logout Configuration	ECC: In the protecting (Resource) Webgate Agent registration, configure the Logout URL as shown in Table 13-3, "Elements on Expanded 11g and 10g Webgate/Access Client Registration Pages" See "Configuring Centralized Logout for 11g Webgates"	DCC: In the DCC Agent registration page the Logout Redirect URL is ignored. In the protecting (Resource) Webgate registration, define the: Logout Redirect URL: http//dcchost:port/oamsso-bin/logout.pl Note: If the Resource Webgate's Logout Redirect URL is anything other than logout.*, then that URL must be defined in the Logout URL parameter of the DCC Webgate registration. For example: If Resource Webgate registration has: Logout Redirect URL http//dcchost:port/someurl.html then DCC Webgate registration must have: Logout URL: someurl.html DCC: Perl path must be updated in Oracle-provided scripts. See "Configuring Logout When Using Detached Credential Collector-Enabled Webgate"

Caveats for Integrated Deployments

When you are using Oracle Identity Management and Oracle Access Management with Oracle Internet Directory, there are two sets of password policy definitions and enforcement.

• Password Policy Definition in both Oracle Identity Management and in Oracle Internet Directory

• Password Policy Enforcement by one of the following:

  Oracle Access Management enforces state policies (incorrect password, for example) during Web access; Oracle Internet Directory enforces its own state policies as well as LDAP operations (bind and compare, for example).

  Oracle Identity Management enforces value policies (characteristics of the password) during user creation of the password update; Oracle Internet Directory enforces it's own value policies as well for policies for LDAP operations (add, modify for example).

To use just one set of policies you can either:

1. Make the Oracle Internet Directory policies weaker or the same strength as the Oracle Identity Management and Oracle Access Management policies. However, this leads to a double enforcement.

2. Disable native LDAP password policy validation, which unfortunately leaves no enforcement for direct LDAP operations.

16.12 Managing Global Password Policy

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.

Access Manager authentication processing relies on an authentication module (or plug-in) to define the rules governing requirements and transmission of information to the back-end authentication scheme. By default, Access Manager supports using the OAM Server Embedded Credential Collector (ECC) for authentication processing. However, you can also configure an 11g Webgate to use as an detached credential collector (DCC) instead.

Both the ECC and DCC facilitate multi-step authentication flows where credentials are not provided all at once. This increases the flexibility of interaction with users or programmatic entities for the purpose of collecting authentication-related information. For more information on multi-factor authentication, see the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

Regardless of the credential collection method you choose (default ECC or optional DCC), you can configure a global password policy as described in this section that applies to all Access Manager-protected resources.

Prerequisites

• Previewing Oracle-Provided Password Forms and Functionality

• Previewing the Password Policy Page in Oracle Access Management Console

• About Credential Collectors and Password Policy Validation

The following overview provides links to topics that describe how to configure and use the password policy. Unless explicitly stated, all tasks apply equally to the ECC and DCC. Skip any tasks that do not apply to your deployment.

Task overview: Password policy management includes

1. Defining Your Global Password Policy

2. Adding Key Password Attributes to the Default Store

3. Adding an Administrator to Change User Attributes After a Password Change

4. Configuring Password Policy Authentication

5. DCC: Configuring 11g Webgate and Authentication Policy for DCC

6. Completing Password Policy Configuration

7. Testing Your Multi-Step Authentication

16.12.1 Defining Your Global Password Policy

Users with Oracle Access Management Administrator credentials can use the following procedure to define a common password policy based on enterprise-defined requirements.

Note:

The only difference between a global password policy for the ECC versus the DCC is Password Service URL, which is credential collector-specific and defaults to ECC pages as shown in Step 2.

The specifications in this example are for illustration only. Your environment will be different.

To configure the password policy in Oracle Access Management

1. From the System Configuration tab, Common Configuration section, expand the Data Source nodes.

   
   System Configuration tab
   Common Configuration section
   Password Policy
   

2. On the Password Policy page, enter the Password Service URL for the desired credential collector login page (ECC or DCC, Table 16-27).

   	ECC Password Service URL	DCC Password Service URL
   	/pages/login.jsp	/oamsso-bin/login.pl

   
   

3. On the Password Policy page, enter values (Table 16-26) based on requirements for your enterprise. For example:

   • Warn After 3

   • Expire After 20

   • Permanent Lockout (Disable)

   • Lockout duration 1

   • Minimum Special Characters 1

4. Click Apply to submit the policy.

5. Proceed as needed for your environment; skip any tasks that have been completed already:

   • Adding Key Password Attributes to the Default Store

   • Adding an Administrator to Change User Attributes After a Password Change

16.12.2 Designating the Default Store for Your Password Policy

The Password Policy operates only with the designated Default Store. Administrator roles and credentials must reside in the System Store.

See Also:

"Setting the Default Store and System Store"

To designate a Default Store for the global password policy

1. From the Oracle Access Management Console, open the User Identity Stores node from the System Configuration tab:

   
   System Configuration tab
   Common Configuration section
   Data Source node
   User Identity Stores node
   

2. Set the System Store: Administrator roles and credentials must reside in this store.

   1. Open the page of the store to designate as the System Store.

   2. Check Set as system store (for domain wide authentication and authorization operations).

   3. Click Applyn.

   4. Add Administrators: See "Managing the Administrators Role".

   5. Authentication Module: Set the LDAP Authentication Module used by the OAMAdminConsoleScheme (authentication scheme) to use this System Store.

   6. Configure one or more authentication plug-ins to use this store, as described in "Orchestrating Multi-Step Authentication with Plug-in Based Modules".

3. Set Default Store: This store is required for Password Policy, Security Token Service, and migration when patching.

   1. Open the page of the store to designate as the Default Store.

   2. Check the box beside Set as default store.

   3. Authentication Module: Locate OAMAdminConsoleScheme and confirm that the LDAP module does not refer to this store. See "Managing Native Authentication Modules".

   4. Authorization Policy Conditions: Choose the desired user identity store when setting Identity Conditions in Authorization Policies. See "Defining Authorization Policy Conditions".

   5. Token Issuance Policy Conditions: Choose the desired user identity store when setting Identity Conditions in Token Issuance Policies. See "Managing Token Issuance Policies, Conditions, and Rules".

4. Close the registration page.

16.12.3 Adding Key Password Attributes to the Default Store

The Password Policy operates only with the designated Default Store. This section provides steps for extending the default store schema for Oracle Access Management password policy operations.

• About Extending the Default Store Schema

• Extending the Default Store Schema with Password Policy Attributes

16.12.3.1 About Extending the Default Store Schema

The LDIF (Lightweight Directory Interchange Format) files distributed as part of Access Manager are meant to extend the schema with required object classes. Generally, these are applied using the idmConfigTool or Access Manager and Oracle Identity Management wiring has been performed manually.

The user data object definition in the Access Manager schema is extended with attributes that enable password user status and password history maintenance. This definition is provided in an LDIF file, and must be added to each user identity store using the ldapadd tool. Oracle-provided LDIFs are identified in Table 16-28.

Note:

OAM_HOME contains installed files necessary to host Oracle Access Management. OAM_HOME resides within the directory structure of the Middleware home.

Table 16-28 Location of Oracle-provided LDIFs for LDAP Providers

LDAP Provider	LDIF Location
OID: Oracle Internet Directory	$OAM_HOME/ oam/server/pswdservice/ldif/OID_PWDPersonSchema.ldif
OVD: Oracle Virtual Directory	$OAM_HOME/ oam/server/pswdservice/ldif/OVD_PWDPersonSchema.ldif
AD: Microsoft Active Directory	$OAM_HOME/ oam/server/pswdservice/ldif/AD_PWDPersonSchema.ldif
SJS: sun Java System Directory	$OAM_HOME/ oam/server/pswdservice/ldif/IPLANET_PWDPersonSchema.ldif
eDirectory: Novell eDirectory	$OAM_HOME/ oam/server/pswdservice/ldif/ED_PWDPersonSchema.ldif
ODSEE: Oracle Directory Server Enterprise Edition	$OAM_HOME/ oam/server/pswdservice/ldif/OJD_PWDPersonSchema.ldif
OUD: Oracle Unified Directory	$OAM_HOME/ oam/server/pswdservice/ldif/OJD_PWDPersonSchema.ldif
SLAPD: OpenLDAP Directory	$OAM_HOME/ oam/server/pswdservice/ldif/OLDAP_PWDPersonSchema.ldif
IBM: OBM Tivoli Directory	$OAM_HOME/ oam/server/pswdservice/ldif/TIVOLI_PWDPersonSchema.ldif

The attributes that enable password user status and password history maintenance are shown in Table 16-29. The user data object of each user identity store must include the attributes shown in Table 16-29. These can be added with the ldapadd tool, LDIF (Lightweight Directory Interchange Format) file.

Table 16-29 Key Password Attributes in a Password Policy

Attribute	Description	Format and Values
obPasswordCreationDate	The date and time used to calculate (at the time of user login) whether the password has expired and whether a warning needs to be issued.	YYYY-MM-DDThh:mm:ssZ
obPasswordHistory	Used to track the number of last passwords used. Access Manager understands 10g oblixPersonPwdPolicy format and changes it to new format.	New format: password1###password2### Previous format: passwordX = SHA256 (password+canonical userid)
obPasswordChangeFlag	Used during forced password change for first time user login (or forced password change initiated by the Administrator.	Boolean string value. true | false Empty string represents false.
obuseraccountcontrol	Used to represent a disabled user.	Non-encrypted string value. activated | deactivated Empty string represents "activated".
obpasswordexpirydate	The time after which the user password is considered to be expired.	YYYY-MM-DDThh:mm:ssZ Empty value represents not expired.
obLockoutTime	The time up to which the user is considered to be locked out due to too many login attempts.	Epoch value (in seconds) representing time in the future. Seconds (since 01 January, 1970)
obLoginTrvCount	The number of consecutive login failures by the user. This counter is reset on the first correct password entry.	Non-encrypted integer value. 1,2,3, and so on.
obLastSuccessfulLoginTime	The time of the last successful login.	YYYY-MM-DDThh:mm:ssZ
obLastFailedLoginTime	The time of the last failed login.	YYYY-MM-DDThh:mm:ssZ

16.12.3.2 Extending the Default Store Schema with Password Policy Attributes

You can skip this task if the environment has been configured using idmConfigTool -prepareIDStore.

If your user identity store has not been extended with the oblix schema, you must update the schema to include the object classes required by the password service.

LDAP tools should be run from the /bin directory beneath OAM_HOME. The following procedure illustrates extending the Oracle Internet Directory schema. Your environment might be different.

To extend the Default User Identity Store schema

1. Use the following command to update the Oracle Internet Directory object classes of the designated Default Store required by the password service:

   ldapadd -D "cn=orcladmin" -w <password> –h <hostname> -p 3060 –x -f $OAM_HOME/
   oam/server/pswdservice/ldif/OID_PWDPersonSchema.ldif
   

2. Proceed to "Adding an Administrator to Change User Attributes After a Password Change".

16.12.4 Adding an Administrator to Change User Attributes After a Password Change

In this procedure, you modify the Default Store (Oracle Internet Directory in this example) to use a different privileged account as the Bind DN. This enables sufficient privileges to change user attributes after a password change.

Prerequisites

Register a supported LDAP store and designate it as the Default Store. Ensure that the user you add is defined within the Default Store.

See Also:

"Managing the Administrators Role"

Figure 16-29 shows the completed registration page for the designated Default Store. The procedure to add an Administrator follows the figure.

Figure 16-29 Default Store with New Administrator Designated

To add a new Administrator

1. Log in to the Oracle Access Management Console, as usual.

        https://hostname:port/oamconsole/
   

2. Open the desired User Identity Store registration page:

   
   System Configuration tab
   Common Configuration section
   Data Sources node
   User Identity Stores
   OID
   

3. Add a New Administrator:

   1. In the Access System Administrators section of the page, click + above the table.

   2. In the dialog box, search All Users, highlight desireduser, then click Add Selected.

   3. Click Apply to submit the changes.

4. Default Store: Confirm the designated Default Store (or click Default Store) then click Apply.

5. Proceed with "Configuring Password Policy Authentication".

16.13 Configuring Password Policy Authentication

After preparing your password policy, Default Store, and Administrator, you can develop your authentication module and scheme as described in this section.

• Configuring the Password Policy Validation Authentication Module

• Configuring the PasswordPolicyValidationScheme

• Adding Your PasswordPolicyValidationScheme to ECC Authentication Policy—If you are using the DCC, skip this topic and go to "Configuring 11g Webgate and Authentication Policy for DCC"

16.13.1 Configuring the Password Policy Validation Authentication Module

You must also configure the Password Policy Validation Authentication Module to use the Default Store.

Note:

There are no credential collector dependencies when defining the Password Policy Validation Module for authentication.

A sample module is shown in Figure 16-30. The User Password Status Step is the unique step that relies on the UserPasswordPolicyPlugin.

Figure 16-30 Password Policy Validation Authentication Module with Orchestrated Plug-ins

Each step identifies the action provided by a specific named plug-in.

See Also:

"Orchestrating Multi-Step Authentication with Plug-in Based Modules" and Table 16-18.

Figure 16-31 shows the orchestration of steps within the authentication module. For more information on modules and steps, see "About Plug-in Based Modules for Multi-Step Authentication".

Figure 16-31 Step Orchestration for Password Policy Validation Module

Table 16-30 describes the Password Policy Validation module step details that you specify.

Table 16-30 User Password Step Details

Step Name	Step Details	Description
User Identification Step	KEY_LDAP_FILTER	Add the LDAP filter to the KEY_LDAP_FILTER attribute. Only standard LDAP attributes can be used when defining an LDAP search filter. For example: (uid={KEY_USERNAME}) See Also: Table 17-22, "LDAP Search Filter Examples for Access Manager" and your vendor documentation for the exact syntax for your identity store
	KEY_IDENTITY_STORE_REF	The name of the registered Identity Store containing the module users. Default: The registered Default Store.
	KEY_SEARCH_BASE_URL	Base URL for user searches. For example: dc=us,dc=example,dc=com
User Authentication Step	KEY_IDENTITY_STORE_REF	The name of the registered Identity Store containing the module users. Default: The registered Default Store.
	KEY_PROP_AUTHN_EXCEPTION	Enable or disable the propagation of LDAP errors.
User Password Status Step	PLUGIN_EXECUTION_MODE	The execution mode of plug-in. Depending upon the configuration, this plug-in can operate either alone or with other default plug-ins. Values are one of the following: PSWDONLY: The most preferred configuration where only the password status is determined. The ID and authentication must be performed using the UserIdentification and UserAuthentication Plugins. AUTHWITHPSWD: Both authentication and password are performed using this plug-in. AUTHONLY: Only the user identification and authentication is performed using this plug-in Default: PSWDONLY
	KEY_IDENTITY_STORE_REF	The name of the registered Identity Store containing the module users. Default: The registered Default Store.
	NEW_USERPSWD_BEHAVIOR	Configures retroactive behavior of the new-user password-policy. Values are either: FORCEPASSWORDCHANGE: Forces a password change. NOFORCEPASSWORDCHANGE: The password policy change does not affect user passwords that are already set. Default: FORCEPASSWORDCHANGE
	POLICY_SCHEMA	Policy schema for password service. Currently only OAM10G is supported. Default: OAM10G
	URL_ACTION	The type of servlet action needed for redirecting the user to the specific password page for expiry and warning pages. Values can be either: REDIRECT_POST REDIRECT_GET FORWARD Default: REDIRECT_POST
	DISABLED_STATUS_SUPPORT	Specifies whether the disabled status is to be supported and acted upon in this password service. Valid values are either True or False. Default: TRUE

Prerequisites

Defining Your Global Password Policy

Note:

There are no credential collector dependencies when defining the Password Policy Validation Module. Enter the Default Store as the KEY_IDSTORE_REF for each of the three plug-ins (with an Error redirect on Failure).

To configure the Password Policy Validation Module

1. From the System Configuration tab, open the:

   
   Access Manager section
   Authentication Modules
   Custom Authentication Modules
   Password Policy Validation Module
   

2. Click the Steps tab; for each of the three steps add the Default Store name in the field beside KEY_IDSTORE_REF (Save after each change). For example:

   1. User Identification Step

      KEY_IDSTORE_REF: OID

      Save.

   2. User Authentication Step

      KEY_IDSTORE_REF: OID

      Save.

   3. User Password Status Step

      KEY_IDSTORE_REF: OID

      Save.

3. Click Apply.

4. Proceed to "Configuring the PasswordPolicyValidationScheme".

16.13.2 Configuring the PasswordPolicyValidationScheme

You can have multiple authentication schemes for use with the global password policy. Users with Administrator credentials can follow this procedure to configure the PasswordPolicyValidationScheme.

Note:

Differences between values for the ECC versus the DCC include (Table 16-27):

• Challenge Redirect URL: Credential Collector host and port

• Challenge URL: Credential Collector Pages

• Challenge Parameters: Table 16-22

The sample scheme in Figure 16-32 is configured for the ECC. Your authentication scheme will be different.

Figure 16-32 Sample ECC PasswordPolicyValidationScheme

Prerequisites

Configuring the Password Policy Validation Authentication Module

See Also:

"Managing Authentication Schemes"

To configure the PasswordPolicyValidationScheme

1. From the System Configuration tab, open:

   
   Policy Configuration tab
   Shared Components
   Authentication Schemes
   PasswordPolicyValidationScheme
   

2. Set up the scheme for your environment. For example:

   • Authentication Level 2

   • Default (blank)

   • Challenge Method: Form

   • Challenge Redirect URL: http://CredCollector_host:port/

   • Authentication Module: Password Policy Validation Module

   • Challenge URL: /CredCollector_pages/

   • Context Type: External

   • Challenge Parameters:

     	ECC Challenge Parameters	DCC Challenge Parameters
     	OverrideRetryLimit=0 initial_command=NONE	OverrideRetryLimit=0 creds=userid password
     		See Also: Table 16-22, "User-Defined Challenge Parameters for Authentication Schemes" action If not specified, the default for both ECC and DCC is /oam/server/auth_cred_submit. DCCCtxCookieMaxLength (default is 4096) TempStateMode controls how the DCC stores the OAM Server state: cookie or form (the default) as specified with the parameter's value. MaxPostDataBytes Restricts the maximum number of bytes of POST data submitted as user credentials. creds Whatever is passed must be specified in the obMap credentials parameter of the ObUserSession object, as described in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management

     
     

3. Click Apply.

4. Proceed to "Adding Your PasswordPolicyValidationScheme to ECC Authentication Policy".

16.13.3 Adding Your PasswordPolicyValidationScheme to ECC Authentication Policy

A user with Administrative privileges can use the PasswordPolicyValidationScheme configured for the ECC in the application domain of the protecting Webgate (Resource Webgate).

Prerequisites

Configuring the PasswordPolicyValidationScheme

To add PasswordPolicyValidationScheme to an ECC authentication policy

1. ECC: In the console, search for and open the appropriate Application Domain. (See "Searching for an Existing Application Domain").

   See Also:

   "Adding PasswordPolicyValidationScheme to Authentication Policy for DCC"

2. ECC: Protect Resources using the PasswordPolicyValidationScheme:

   1. Find and open your Protected Resource Policy on the Authentication Policies tab (see "Viewing or Editing an Authentication Policy"):

      
      Authentication Policies
      Protected Resource Policy

   2. Select PasswordPolicyValidationScheme for the Protected Resource Policy (Authentication Scheme) and click Apply.

   3. Finish updating your Authentication and Authorization policies, as desired (Chapter 17).

3. Proceed as needed for your environment:

   • ECC: Completing Password Policy Configuration

   • DCC: Configuring 11g Webgate and Authentication Policy for DCC

16.14 Configuring 11g Webgate and Authentication Policy for DCC

If your environment uses the ECC, skip this section and go to "Completing Password Policy Configuration".

Task overview: Configuring 11g Webgate and authentication policy for DCC

1. Enabling DCC Credential Operations provides steps for either configuration:

   DCC Combined with Resource Webgate: Enable Allow Credential Collector Operations in the DCC's OAM Agent registration page.

   Separate DCC and Resource Webgate: Enable Allow Credential Collector Operations in the DCC's OAM Agent registration page and edit the Resource Webgate registration page to set the Logout Redirect URL to the DCC's logout.pl.

2. Locating and Updating DCC Forms for Password Policy

3. Adding PasswordPolicyValidationScheme to Authentication Policy for DCC provides steps for either configuration:

   DCC Combined with Resource Webgate: In the combined DCC/Resource Webgate Application Domain, update the Protected Resources Authentication Policy to use your DCC Authentication Scheme.

   Separate DCC and Resource Webgate: In the separate Resource Webgate Application Domain, update the Protected Resources Authentication Policy to use your DCC Authentication Scheme.

16.14.1 Enabling DCC Credential Operations

Whether you are using a separate DCC or combined DCC and Resource Webgate, you must enable Allow Credential Collector Operations in the DCC's OAM Agent registration page.

With a separate DCC and Resource Webgate, you must also edit the Resource Webgate registration page to set the Logout Redirect URL to the DCC's logout.pl, as described in Step 3.

The following procedure presumes your deployment uses Open mode communication. If your deployment uses Simple or Cert mode communication, be sure to copy the appropriate artifacts when you perform Step 4.

Prerequisites

• Configuring and Managing Registered OAM Agents Using the Console

• Managing Global Password Policy

• Configuring Password Policy Authentication using DCC-specific details

To enable DCC credential operations

1. Using the Oracle Access Management Console, find and open the registration page for the 11.1.2 Webgate that will function as the DCC:

   
   System Configuration tab
   Access Manager section
   SSO Agents node
   DCCAgent
   

2. DCC Webgate Registration: Check Allow Credential Collector Operations, click Apply, then perform Steps 4 and 5.

   Note:

   If the DCC is combined with a Resource Webgate, skip Step 3.

3. Separate Resource Webgate: Edit the Resource Webgate registration to set the Logout Redirect URL to the DCC's logout.pl (Table 16-27), click Apply, then perform Steps 4 and 5.

4. Copy Agent configuration file (including Simple or Cert mode files) from the AdminServer (Console) host to the Agent host. For example:

   	Agent & Artifacts	Artifacts
   	11g Webgate/Access Client ObAccessClient.xml and cwallet.sso	From the AdminServer (Console) host: $DOMAIN_HOME/output/$Agent_Name/ To the Agent host: $11gWG_install_dir/webgate/config
   	Simple or Cert Mode	Copy to the Agent host: $11gWG_install_dir/webgate/config aaa_key.pem aaa_cert.pem aaa_chain.pem password.xml See Also: Appendix C, "Securing Communication"

   
   

5. Restart the OHS Web server.

6. Proceed to "Locating and Updating DCC Forms for Password Policy".

16.14.2 Locating and Updating DCC Forms for Password Policy

Access Manager provides several dynamic pages for user interactions with the DCC.

See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Access Management

Prerequisites

Enabling DCC Credential Operations

To locate and update the DCC forms

1. Locate the DCC forms in the Webgate host (Table 16-27):
WEBGATE_HOME/webgate/ohs/oamsso/*,
WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl, and
WEBGATE_HOME/webgate/ohs/oamsso-bin/templates/*.

2. Customize their location, depending on the desired topology of the authentication scheme being developed.

3. Update Perl Location: Update the Perl location to be consistent with the actual location, in the first line of the login, logout, and securid scripts on Webgate host in WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl ("Perl Scripts for DCC-based Login and Logout" in Table 16-27).

4. Customize the default pages for your enterprise, or replace them entirely with custom pages. For example, you can design, implement, and deploy a custom page that displays a different version of the login form for a mobile browser than is used for a desktop browser.

5. Proceed to "Adding PasswordPolicyValidationScheme to Authentication Policy for DCC".

16.14.3 Adding PasswordPolicyValidationScheme to Authentication Policy for DCC

The following procedure provides steps that you must perform to use your DCC Authentication Scheme in a Protected Resources Authentication Policy. The steps you perform depend on the type of deployment you have:

• Combined DCC/Resource Webgate: Perform Step 1 to add your DCC Authentication Scheme to the Protected Resources Authentication Policy of the combined DCC/Resource Webgate Application Domain.

• Separate Resource Webgate: Perform Step 3 to add your DCC Authentication Scheme to the Protected Resources Authentication Policy of the separate Resource Webgate Application Domain.

Perform Step 2 regardless of your DCC deployment type. By default, login and logout forms are excluded through OHS /httpd.conf/webgate.conf so that you do not need to exclude them through policies. However, with the Chrome browser, you must explicitly exclude the async favicon.ico request (which overrides the DCCCtxCookie).

Note:

This example refers to the PasswordPolicyValidationScheme set for the DCC earlier.

Prerequisites

Locating and Updating DCC Forms for Password Policy

To use the DCC Authentication Scheme in an Authentication Policy

1. Combined DCC/Resource Webgate: Open the DCC application domain:

   
   Policy Configuration
   Application Domains
   DCCDomain
   

   1. Locate and open the Authentication Policy, Protected Resource Policy (see "Searching for an Authentication Policy").

   2. Add your DCC Authentication Scheme to this policy (see "Defining Authentication Policies for Specific Resources").

      
      PasswordPolicyValidationScheme (DCC Authentication Scheme)
      

   3. Perform Step 2 if you have the Chrome Browser. Otherwise, go to Step 4.

2. Chrome Browser: Add and exclude resource /favicon.ico in the DCCDomain, as follows.

   1. From DCCDomain, click the Resources tab.

   2. Find and open the HTTP resource /favicon.ico (or click the New Resource button and then add this resource).

   3. Confirm or edit the Resource URL to:

      /favicon.ico
      

   4. In the Protection section, Protection Level list, select Excluded, then click Apply.

   5. Proceed to Step 4.

3. Separate Resource Webgate: Open the Resource Webgate application domain.

   
   Policy Configuration
   Application Domains
   ResourceWGDomain
   

   1. Locate and open the Authentication Policy, Protected Resource Policy (see "Searching for an Authentication Policy").

   2. Add your DCC Authentication Scheme and an optional Failure URL (when not specified, Failure URL displays the default error page) to this policy (see "Defining Authentication Policies for Specific Resources"):

      
      DCC Authentication Scheme
      Failure URL (optional)
      

   3. Perform Step 2 if you have the Chrome Browser. Otherwise, go to Step 4.

4. Restart your Web server and proceed to "Completing Password Policy Configuration".

   See Also:

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

16.15 Completing Password Policy Configuration

These tasks are the same regardless of the credential collector you have configured. Perform the following tasks to complete your password policy configuration:

• Setting the Error Message Mode for Password Policy Messages

• Overriding Native LDAP Password Policy Validation

• Disabling ECC Operation and Using DCC Exclusively

• Testing Your Multi-Step Authentication

16.15.1 Setting the Error Message Mode for Password Policy Messages

Users with administrative privileges can use this procedure to set the Server Error Mode for password policy messages, as shown in Figure 16-33.

Figure 16-33 Server Error Mode for Password Management

Prerequisites

• Managing Global Password Policy

• Configuring Password Policy Authentication

• Optional: Configuring 11g Webgate and Authentication Policy for DCC

To set the error message mode

1. In the console, open the Access Manager section:

   
   System Configuration
   Access Manager
   Access Manager Settings
   

2. In the Load Balancing section, set the Server Error Mode to Internal.

3. Click Apply.

4. Proceed with "Overriding Native LDAP Password Policy Validation".

16.15.2 Overriding Native LDAP Password Policy Validation

As described earlier, you need to disable native LDAP password policy validation before the non-native password policy can be used.

For example, with Oracle Internet Directory registered for Oracle Access Management, native password policy is generally located as follows:

dn: cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,<DOMAIN_CONTAINER>

Caution:

Disabling the native LDAP password policy validation leaves no enforcement for direct LDAP operations. There are various password policies in Oracle Internet Directory, including one in the following:

dn: cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext

However, this might not apply to your domain.

You can disable the Oracle Internet Directory password policy by setting the orclpwdpolicyenable parameter to zero (0).

See Also:

The various attributes described in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory

The following procedure is only an example. Your environment will be different.

Prerequisites

Setting the Error Message Mode for Password Policy Messages

To override native LDAP policy with Oracle Access Management password policy

1. Refer to the manual from your LDAP directory vendor.

2. Oracle Internet Directory: Disable native policy by setting orclpwdpolicyenable to zero (0).

   • Confirm the location of the password policy for your domain.

   • When you are sure you have the proper native LDAP policy, disable the policy. For example:

     orclpwdpolicyenable = 0
     

3. Proceed as follows, depending on your deployment:

   • "Disabling ECC Operation and Using DCC Exclusively"

   • "Testing Your Multi-Step Authentication"

   • Chapter 19: "Configuring Logout When Using Detached Credential Collector-Enabled Webgate"

16.15.3 Disabling ECC Operation and Using DCC Exclusively

You can skip this task to allow the DCC and ECC to co-exist, and maintain authentication schemes and policies for both credential collectors.

To disable ECC, you must edit the oam-config.xml file as described here. Generally, Oracle recommends not editing oam-config.xml. Changes to this file could result in lost data or overwriting of the file during data sync operations. However, there is no other way to disable the ECC completely in favor of the DCC.

Note:

After disabling the ECC, access to resources protected by schemes and policies that rely on the ECC will be prohibited, including access to the Oracle Access Management Console.

Prerequisites

Configuring 11g Webgate and Authentication Policy for DCC

To disable ECC operation and use DCC exclusively

1. Make your changes on the node running the AdminServer to minimize possible conflicts that another AdminConsole user might make.

2. Back up oam-config.xml in $DOMAIN_HOME/config/fmwconfig/ and store the copy in a different location for use later if needed.

3. Locate the ECCEnabled parameter in the OAMServicesDescriptor section and make the changes shown here in bold:

   <Setting Name="OAMServicesDescriptor" Type="htf:map">
     ... ...
      <Setting Name="ECCEnabled" Type="htf:map"> 
      <Setting Name="ServiceStatus" Type="xsd:boolean">false</Setting>
   </Setting>      
   

4. Increment by 1, the configuration version number at the top of the file to associate your change and enable automatic propagation and dynamic activation across all running OAM Servers (see the next to last line of this example):

   <Setting Name="Version" Type="xsd:integer">
     <Setting xmlns="http://www.w3.org/2001/XMLSchema"
       Name="NGAMConfiguration" Type="htf:map:> 
     <Setting Name="ProductRelease" Type="xsd:string">11.1.1.3</Setting>
       <Setting Name="Version" Type="xsd:integer">2</Setting>
   </Setting> 
        
   

5. Proceed to "Testing Your Multi-Step Authentication".

16.15.4 Testing Your Multi-Step Authentication

This section provides a number of evaluations you can perform to confirm that your deployment is working properly.

See Also:

Chapter 19, "Configuring Centralized Logout for Sessions Involving 11g Webgates"

To confirm your multi-step authentication

1. Confirm access after login:

   1. Open a new browser and request a resource.

   2. Log in with your user credentials.

   3. Confirm that you have access to the resource.

2. Confirm no access on incorrect login:

   1. Open a new browser and request a resource.

   2. Log in with incorrect user credentials.

   3. Confirm that you must re-authenticate.

3. Confirm lockout after exceeding maximum incorrect login attempts:

   1. Open a new browser and request a resource.

   2. Log in with incorrect user credentials repeatedly.

   3. Confirm that the user account is locked.

4. Modify and evaluate your password expiry policy:

   1. Log in to the Oracle Access Management Console.

   2. In your password policy, reset the expiry and lockout periods (Table 16-26) so that you will see warnings on your next login.

   3. Save the policy updates.

   4. Open a new browser and request a resource.

   5. Verify the warning page appears advising that the password will expire.

   6. Click the link to continue without password change.

5. Change your password:

   1. Open a new browser and request a resource.

   2. On the password expiry warning page, click the link to change your password.

   3. On the password change page, enter your correct old password.

   4. In the new password field, enter a different new password that does not follow the password policy and confirm the password validation error.

   5. Enter a new password that meets requirements and confirm success and access to the resource.

16.16 Configuring Authentication Post Data Handling

Post data preservation and restoration functions apply to both credential collectors (ECC or DCC). This section provides the following topics:

• About Authentication Post Data Preservation and Restoration

16.16.1 About Authentication Post Data Preservation and Restoration

Post data preservation and restoration functions come into play when an application has a form in which the user enters credential data, but the session has expired by the time the user submits the form (or if there is no user session when posting the application form). If the session expires (or does not exist), the user is presented with a fresh login form unless post data is preserved and restored.

Administrators can configure the Resource Webgate to perform post data preservatio when the expired user and newly authenticated user are the same. Table 16-31 describes Resource Webgate support and behavior for post data.

Table 16-31 Resource Webgate Support of Post Data Preservation and Restoration

Resource Webgate	Description
Supports Authentication Schemes	LDAP, Basic, Sessionless Basic, X509, WNA
Supports form encoding	with text/html, text/plain, multipart/form-data, and application/x-www-form-urlencoded type data posted by the application form.
Preserves	The encoding type of the data posted by the original application form, except the input field of file type.
Ensures	The downstream application sees the same post data that was posted by the original application form.
Constrains	The overall size of the inbound request data or the inbound front channel message. There shall be a configuration parameter to override the code default value. This shall be per application.
Maintaiuns application data confidentiality and integrity	Neither the Resource Webgate nor credential collector will interpret, nor log, application post data. If, after expiration and during re-authentication, the user authenticates with different credentials, then the post data of the previous user is cleared by the Resource Webgate and not restored. However, Webgate will post to the downstream application URL that was posted by the original application form.
Ignores Preservation if ... Logs a Warning when ... Performs Standard Authentication if ... Shows an Error when ...	Post data is larger than the hard-coded limit, preservation is ignored. Post data is skipped because it is bigger than the allowed limit, a warning is logged. Post data size is larger than the hard-coded limit (or the configured value), the standard authentication flow is used. Together, if both front channel message data and application post data are large an error occurs.

Table 16-32 describes credential collector support for post data handling.

Table 16-32 Credential Collector Support for Post Data Handling

ECC and DCC
Remain compatible with earlier 11g Webgates
Support post data preservation for Form based authentication scheme with the default login form provided out of the box.
Preserve applications post data during authentication processing: Challenging the user Re-challenging the user if invalid credentials are provided Do not interpret application post data.
Constrain the overall size of inbound front-channel messages using a configuration parameter to override the default value, per application.
Log a warning when post data is skipped because it is larger than the allowed limit.
Do not preserve application post data when: Authentication policy is configured with Success or Failure authentication URLs Password management (password expiration and so on) is involved Integration scenarios where Access Manager is used for performing authentication through custom agents.

ECC Only

The embedded credential collector does not support post data handling with the external login page

DCC Only

With the DCC, post data is preserved through the HTTP header, and the amount of post data that can be handled to 8192 characters.

The detached credential collector does not support custom login pages. The DCC does not support post data restoration during password management operations.

With the DCC, post data restoration with a Form-based Authentication Scheme requires the challenge parameter TempStateMode=form.

16.16.2 About Configuring Authentication Post Data Handling

16.16.3 Configuring Authentication Post Data Handling

16.16.4 Testing Post Data Handling Configuration

16.17 Configuring Long URL Handling During Authentication

Long URL handling applies to both credential collectors (ECC or DCC).

This section provides the following topics:

• About Long URLs and Authentication Handling

16.17.1 About Long URLs and Authentication Handling

Authentication involves redirecting the user's request to a centralized component that performs authentication, known as a Credential Collector. The mechanism used to redirect user from the policy enforcement point (OAM Agent) to the Credential Collector, is a proprietary front channel protocol over HTTP. This protocol currently provides the context of the request and the authentication response on the query string. In situations where the URL of the requested page is larger, the overall context becomes larger and can go beyond the browser's permissible size. This is referred to as Long URL Handling.

By default, the Resource Webgate checks the payload size of the front channel protocol message to determine if it is larger than the coded limit. When long URL handling is explicitly enabled, the limit is ignored and has no impact.

The credential collector determines if the front channel response payload is to be sent as HTTP Post data when:

• The incoming request indicates that the agent is capable of handling HTTP POST or REDIRECT type of response

• The credential collector is configured to always send the payload as HTTP post data

• The credential collector is configured to always send the payload as a query string

If no explicit configuration is present, then if the payload size is greater than predefined limit, then it shall send payload as the HTTP post data. But if the payload size is lower than the predefined limit, then it shall send it on the query string.

Note:

If application post data is also preserved there is no impact.

Table 16-33 identifies Long URL handling functionality with both the ECC and DCC.

Table 16-33 ECC and DCC: Long URL Handling

ECC Long URL Handling	DCC Long URL Handling
ECC is compatible with all 11g Webgates.	Same as ECC.
N/A	Long URL handling is limited to the maximum allowed size of the DCCContextCookie. There is no support to preserve the front channel payload on the form.

16.17.2

16.17.3

16.17.4