19 Managing Authentication and Shared Policy Components

19.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 configure 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.

Table 19-1 compares resource types and operations.

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

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

Figure 19-1 Default HTTP Resource Type Definition

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

The wl_authen resource type is shown in Figure 19-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 19-2 Default Resource Type wl_authen

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

Figure 19-3 Default Resource Type TokenServiceRP Resource Type

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

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

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

19.3.3 Searching for a Specific Resource Type

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

To search for a resource type

1. From the Oracle Access Management Console, click Resource Types.

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.

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

To create a custom resource type

1. From the Oracle Access Management Console, click Resource Types.

2. 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 Policy Resource Definitions".

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

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

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

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.

AuthType Oblix
require valid-user

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

ServerAdmin webmaster@example.net
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

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

Figure 19-4 Host Identifier Page

Description of "Figure 19-4 Host Identifier Page"

Table 19-4 describes the host identifier definition.

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

To manually create a Host Identifier

1. From the Oracle Access Management Console, click Host Identifiers.

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.

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

To find for a host identifier

1. From the Oracle Access Management Console, click Host Identifiers.

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.

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

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

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

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.

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.

19.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 50, "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.

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

19.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 19-5.

which perl
/usr/bin/perl

/usr/local/bin/perl

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

19.6.1 About Native Access Manager Authentication Modules

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

19.6.1.1 Native Kerberos Authentication Module

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

Figure 19-5 Native Kerberos Authentication Module

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

Table 19-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 19-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).

19.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 19-6. Additional details follow the figure.

Figure 19-6 Native LDAP Authentication Module

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

Table 19-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 19-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 OAM 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".

19.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 19-7 Native X509 Authentication Module

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

Table 19-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 19-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 me@example.com and it must be matched against the "mail" LDAP Attribute, an LDAP query must search LDAP against the "mail" attribute with a value "me@example.com (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.

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

To find, view, or edit an authentication module

1. From the Oracle Access Management Console, click Authentication Modules.

2. Open the desired Authentication Modules page.

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

   • Kerberos Module: See Table 19-7

   • LDAP Module: See Table 19-8

   • X509 Module: See Table 19-9 and Table 19-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".

19.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. From the Oracle Access Management Console, click Authentication Modules.

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

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

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

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

• Authentication can be retried upon failure.

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 19-10 provides more information about these two forms of authentication.

19.7.2 About Plug-ins for Multi-Step Authentication Modules

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

Plug-ins operate with either the default embedded credential collector (ECC) or the optional detached credential collector (DCC-enabled Webgate). Each authentication 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 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.

Figure 19-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 19-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.

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.

Additionally, when multi-factor authentication is used, the UserIdentificationPlugin should be invoked in the last pass during the authentication process.

Figure 19-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 19-9 Creating Custom Authentication Modules: General

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

Table 19-11 describes the content of the General tab.

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 19-10 Adding a Step and Associating a Plug-in

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

Table 19-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 19-13 describes the Plug-in Parameter Details required by Oracle-provided plug-ins. Absent from this table are the plug-in exceptions (those plug-ins with no initial parameters): KerberosTokenIdentifier, FedAuthnRequestPlugin, and FedUserAuthenticationPlugin.

CRED_PARAM_1=
{ID=KEY_USERNAME},{DISPLAY_NAME=KEY_USERNAME},{TYPE=text}
{ID=KEY_PASSWORD},{DISPLAY_NAME=KEY_PASSWORD},{TYPE=password}

Figure 19-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 19-11 Plug-in Based Authentication Module Steps and Details

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

Figure 19-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 19-12 Steps Orchestration for Plug-in Based Authentication Modules

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

Table 19-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)

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

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

Figure 19-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

KerberosPlugin

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

Figure 19-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 19-14 KerberosPlugin

Description of "Figure 19-14 KerberosPlugin"

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

Figure 19-15 Default KerberosPlugin Steps and Details

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

Figure 19-16 Default KerberosPlugin Steps and Orchestration

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

LDAPPlugin

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

Figure 19-17 LDAPPlugin

Description of "Figure 19-17 LDAPPlugin"

Figure 19-18 Default LDAPPlugin Steps and Details

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

Figure 19-19 Default Orchestration of Steps for LDAPplugin

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

X509Plugin

Figure 19-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 19-21 shows default steps and details for this plug-in. Figure 19-22 shows the default orchestration of steps for the X509Plugin.

Figure 19-20 X509Plugin

Description of "Figure 19-20 X509Plugin"

Figure 19-21 X509Plugin Default Steps and Details

Description of "Figure 19-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 19-15 lists the stepX509 values for Subject and Subject Alternative Names. Such processing is only supported when the X509Plugin is used.

Figure 19-22 Default Orchestration for X509Plugin Steps

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

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 19-23 shows the Steps tab. Additional details follow the figure.

Figure 19-23 Password Policy Validation Module Plug-ins

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

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

19.7.4 Example: 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, click Authentication Modules, Custom Authentication Modules and 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 19-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 Certificate Validation and Revocation"

   1. From the Oracle Access Management Console, click 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.

19.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).

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 the Oracle Access Management Console, click Authentication Modules.

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 19-12, Table 19-13, Table 19-17, "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 19-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 19-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".

19.7.6 Creating and Managing Step-Up Authentication

This section describes how to define step-up authentication using plug-ins within a customized module. In this example, there are users who need standard level access to pages on the corporate portal and those who need access to sensitive information. For standard applications, authentication credentials include username and password. For sensitive applications, credentials include username, password, and a security code (the later obtained with a custom plugin that validates the code).

Figure 19-25 shows the steps within Step-up-Authn_Module. The processing that occurs with this customized step-up authentication module is driven by the steps and plug-ins described in Table 19-16. For more information, see Table 19-13.

Figure 19-25 StandardLevelCheck-2 and SensitiveLevelCheck-6 Modules

After defining and orchestrating plug-ins in an authentication module, you can use the module in an authentication scheme and use the scheme in a policy.

Task overview: Configuring Step-up Authentication

1. Create or edit a custom authentication module for step up authentication:

   
   

2. Define your custom authentication module based on the Steps shown here.

   
   

3. Orchestrate your Steps and Plug-ins as shown here and described in Table 19-16.

   
   

4. Sensitive Scheme: Create or edit an Authentication Scheme for sensitive applications that uses your customized step-up authentication module . For example:

   See Also:

   "Managing Authentication Schemes"
   
   

5. Lower-Level Scheme: Create or edit an Authentication Scheme for the lowest level applications using your customized step-up authentication module F.or example:

   
   

6. Sensitive Policy: Create or edit an Authentication Policy for sensitive-level resources using your customized step-up Authentication Scheme. For example:

   See Also:

   Chapter 20, "Managing Policies to Protect Resources and Enable SSO"
   
   

7. Lower-Level Policy: Create or edit an Authentication Policy for the lowest level resources using your customized step-up Authentication Scheme. For example:

   
   

8. Verify: Verify your resources and the policies that protect them. For example:

   
   

19.7.7 Configuring an HTTPToken Extractor Plug-in

The following process should be followed to configure an HTTPToken Extractor plug-in.

1. Create a sample plug-in that will re-direct the user to the authenticating application.

   The authenticating application will authenticate the user and set the user name in the HTTP header or cookie.

2. Create a custom authentication module that will access any applicable plug-ins.

   For example, if you add the plug-in created in the previous step and the HTTPToken Extractor and User identification plug-ins, successful authentication occurs when the process for all three plug-ins has been successfully completed.

3. Add values for the header name and the user search filter properties.

   The KEY_HEADER_PROPERTY is set in the HTTPToken Extractor plug-in while KEY_LDAP_FILTER is set in the UI plug-in. For example:

   • KEY_HEADER_PROPERTY = cookieorheadername

   • KEY_LDAP_FILTER = (uid={cookieorheadername})

   Note:

   The user should be present in the data store which is being used.

19.7.8 Configuring a JSON Web Token Plug-in

Use this plug-in when you need to protect REST or Web services using standard tokens. The JSON Web Token Plug-in issues both an OAM token and a Mobile and Social JWT token that can be used for Web services access. Oracle API Gateway and Oracle Web Services Manager can use this JWT token for Web services protection.

19.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 19-26 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 19-26 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 19-17.

Table 19-18 describes elements in the Plugins status table.

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

Figure 19-27 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 19-19; see also, Table 19-13.

Table 19-19 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.

19.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. Log in to the Oracle Access Management Console.

      https://hostname:port/oamconsole/
      

   2. From the Oracle Access Management Console, click Plug-ins 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

19.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 Oracle Access Management Console, click Plug-ins 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

19.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. Log in to the Oracle Access Management Console. For example:

   https://hostname:port/oamconsole/
   

2. From the Oracle Access Management Console, click Plug-ins.

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

19.9.1 About Authentication Schemes and Pages

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

Figure 19-28 Default LDAPScheme Page

Description of "Figure 19-28 Default LDAPScheme Page"

Table 19-20 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.

About Custom Login Pages

Only Schemes with the Challenge Method of FORM, X509, or DAP include additional elements described at the end of Table 19-20. 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

<enforce-valid-basic-auth-credentials>false
   </enforce-valid-basic-auth-credentials>

<parmatername>=<value>

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

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

To create an authentication scheme

1. From the Oracle Access Management Console, click Authentication Schemes.

2. Click the Create button in the tool bar.

3. Fill in the fresh Authentication Scheme page (Table 19-20) 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 19-22, Table 19-23, Table 19-30

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

19.9.4 Searching for an Authentication Scheme

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

To search for an authentication scheme

1. From the Oracle Access Management Console, click Authentication Schemes.

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

   OA*
   

3. Click the Search button to initiate the search.

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

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

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

To view or modify an authentication scheme

1. From the Oracle Access Management Console, click Authentication Schemes and find the desired scheme.

2. Edit:

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

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

19.10.1 Using Pre-Authentication Advanced Rules

For user authentication, a form-based login page is presented through the browser for the user to complete. In some cases, a non-browser client (switches, routers and the like) might need to do basic authentication based on credentials passed via the request header. (This might arise when a particular resource protected by a form-based authentication scheme can be accessed by both users with a browser as well as switches, routers and other types of non-browser clients.) Non-browser client authentication support has been added (and can be configured) as one of the pre-authentication Advanced Rules. To support non browser client authentication, a user can configure the desired condition in an Authentication Rule (based on the HTTP request header's availability) and set a desired outcome.

Before executing the Authentication Condition, the Access Manager server prepares a request context using the available Request data (to construct a Boolean expression based condition). The following tables describe the various request context data details.

• Table 19-25, "Request Context Data"

• Table 19-26, "Location Context Data"

• Table 19-27, "Session Context Data"

• Table 19-28, "User Context Data"

19.10.2 Understanding Sample Advanced Rules

Table 19-29 contains sample Advanced Rules.

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

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

ssoCookie=

miscCookies=

       Secure

ssoCookie=Secure
miscCookies=Secure

ssoCookie=disableSecure
miscCookies=disableSecure

       httponly

ssoCookie=httponly
miscCookies=httponly

       disablehttponly

ssoCookie=disablehttponly
miscCookies=disablehttponly

ssoCookie=max-age=time-in-seconds

max-age=2592000

19.11.2 Configuring Challenge Parameters for Security of Encrypted Cookies

The challenge parameter is not case sensitive.

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 19-30).

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

19.11.3 Setting Challenge Parameters for Persistence of Encrypted Cookies

The challenge parameter is not case sensitive.

To define encrypted cookie persistence

1. Define an authentication scheme.

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

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

19.12.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 19-32 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 19-32 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.

19.12.2 Previewing the Password Policy Page in Oracle Access Management Console

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

Figure 19-29 Password Policy Configuration Page

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

19.12.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 19-34.

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.

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

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 Oracle Access Management Console, click Password Policy under the Access Manager panel.

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

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

   
   

3. On the Password Policy page, enter values (Table 19-33) 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

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

To designate a Default Store for the global password policy

1. From the Oracle Access Management Console, click User Identity Stores.

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.

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

$OAM_HOME/
oam/server/pswdservice/ldif/OID_PWDPersonSchema.ldif

$OAM_HOME/
oam/server/pswdservice/ldif/OVD_PWDPersonSchema.ldif

$OAM_HOME/
oam/server/pswdservice/ldif/AD_PWDPersonSchema.ldif

$OAM_HOME/
oam/server/pswdservice/ldif/IPLANET_PWDPersonSchema.ldif

$OAM_HOME/
oam/server/pswdservice/ldif/EDIR_PWDPersonSchema.ldif

$OAM_HOME/
oam/server/pswdservice/ldif/IPLANET_PWDPersonSchema.ldif

        $OAM_HOME/
oam/server/pswdservice/ldif/OUD_PWDPersonSchema.ldif

$OAM_HOME/
oam/server/pswdservice/ldif/OLDAP_PWDPersonSchema.ldif

$OAM_HOME/
oam/server/pswdservice/ldif/TIVOLI_PWDPersonSchema.ldif

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

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

Figure 19-30 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".

19.14.1 Configuring the Password Policy Validation Authentication Module

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

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

Figure 19-31 Password Policy Validation Authentication Module with Orchestrated Plug-ins

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

Figure 19-32 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 19-32 Step Orchestration for Password Policy Validation Module

Table 19-37 describes the Password Policy Validation module step details that you specify.

(uid={KEY_USERNAME})

dc=us,dc=example,dc=com

Prerequisites

Defining Your Global Password Policy

To configure the Password Policy Validation Module

1. From the Oracle Access Management Console, click Authentication Modules, Custom Authentication Modules and then 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".

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

The sample scheme in Figure 19-33 is configured for the ECC. The sample scheme in Figure 19-34 is configured for the ECC. Your authentication scheme will be different.

Figure 19-33 Sample ECC PasswordPolicyValidationScheme

Figure 19-34 Sample DCC PasswordPolicyValidationScheme

Prerequisites

Configuring the Password Policy Validation Authentication Module

To configure the PasswordPolicyValidationScheme

1. From the Oracle Access Management Console, click Authentication Schemes and then 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 19-23, "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".

19.14.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 20).

3. Proceed as needed for your environment:

   • ECC: Completing Password Policy Configuration

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

19.15.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. In the Access Manager section of the Oracle Access Management Console, click SSO Agents to find and open the registration page for the 11.1.2 Webgate that will function as the DCC.

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 19-34), 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".

19.15.2 Locating and Updating DCC Forms for Password Policy

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

Prerequisites

Enabling DCC Credential Operations

To locate and update the DCC forms

1. Locate the DCC forms in the Webgate host (Table 19-34):
$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 19-34).

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

19.15.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).

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"

19.15.4 Supporting Federation Flows With DCC

The DCC is enhanced to work as a public end-point to the Access Manager server. HTTP requests to the DCC are tunneled via NAP to the proxy module of the Access Manager server. The JSP pages and servlets are executed in the Access Manager server and the response is tunneled back to the DCC. The end user effectively communicates only to the DCC.

To use DCC for converged Federation flows, perform the following manual steps.

1. Configure the following internal resources as Public instead of Excluded.

   /oamfed/…/*
   /oam/…/*
   /…/*
   

2. In the DCC WebGate, set the logout value to a valid DCC WebGate logout URL; for example, /oamsso-bin/logout.pl

3. Update the DCC Agent entry by adding the following entry to the User Defined Parameters list using the Access Manager Administration Console.

   TunneledUrls=/oam,/oamfed
   

19.16.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 19-35.

Figure 19-35 Server Error Mode for Password Management

Prerequisites

• Managing Global Password Policy

• Configuring Password Policy Authentication

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

To set the error message mode

1. From the Oracle Access Management Console, click 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".

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

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

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

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 22: "Configuring Logout When Using Detached Credential Collector-Enabled Webgate"

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

Prerequisites

Configuring 11g WebGates 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".

19.16.4 Testing Your Multi-Step Authentication

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

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 19-33) 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.

19.17.1 About Authentication Post Data Preservation and Restoration

POST data preservation and restoration functions come into play when an application has a form wherein the user has entered a credential (or other data) but the session has expired, an idle session timeout has occurred, or the token validity period has ended by the time the user submits the form. If this scenario occurs, the user is presented with a fresh login form (depending on the authentication scheme) unless POST data is preserved and restored.

Administrators can configure the Resource Webgate to perform POST data preservation when the expired user and newly authenticated user are the same. Table 19-38 describes Resource Webgate support and behavior for post data.

Table 19-39 describes credential collector feature support for POST data handling.

19.17.2 About Configuring Authentication POST Data Handling

Table 19-40 summarizes the authentication schemes that support authentication POST data handling.

Table 19-41 summarizes complete configuration requirements for authentication POST data handling. All requirements described in Table 19-41 are supported end to end with the authentication schemes in Table 19-40.

19.17.3 About Post Data Size Limits

Assuming the usual form data entered by users is about several kilobytes, putting a limit on data comsumption from the incoming request is a general requirement. The data transferred in the front channel protocol (either request or response) must also go through the size check. Considering these situations:

• Limit the size of data passed to the OAM Server on the back channel using the maxpostdatabytes authentication challenge parameter

  In cases where the DCC is used, the maxpostdatabytes authentication challenge parameter performs this check on the overall POST data.

• Limit the size of the POST data from the end user application using MaxPreservedPostDataBytes authentication scheme challenge parameter.

  The MaxPreservedPostDataBytes authentication scheme challenge parameter handles this. Additionally, this can be set as a user-defined Webgate parameter.

• Limit size of the front channel payload on obrar.cgi or obrareq.cgi with a Webgate user-defined parameter ChallengeRedirectMaxMessageBytes.

19.17.4 Configuring Authentication POST Data Handling

Be sure to read all POST data topics in this section before attempting this procedure. There is no need to make any explicit change in your authentication scheme.

To configure authentication POST data handling

1. Configure the Authentication Scheme:

   1. From the Oracle Access Management Console, create or find the desired scheme (Table 19-40).

   2. On the Authentication Scheme page, modify values for POST data handling.

      This example uses the embedded credential collector (Table 19-20) and values for POST data handling (Table 19-23):

      
      Name: DesiredScheme
      Authentication Level 2
      Challenge Method: Form
      Challenge Redirect URL: /oam/server/
      Authentication Module: LDAP
      Challenge URL: /pages/login.jsp
      Context Type: External
      Challenge Parameters

      Authentication Scheme Challenge Parameters for Post Data with ECC	Authentication Scheme Challenge Parameters for Post Data with DCC
      MaxPreservedPostDataBytes=9000	MaxPreservedPostDataBytes=9000 TempStateMode=form

      
      

   3. Click Apply to submit the changes.

2. ECC: Configure serverRequestCacheType, the OAM parameter in oam-config.xml, if using ECC.

   1. Stop the managed server.

   2. Stop the administration server.

   3. Open oam-config.xml and modify the value of serverRequestCacheType.

   4. Save the file.

   5. Restart the administration server.

   6. Restart the managed server.

3. Configure Webgate Parameters for POST data handling:

   1. From the System Configuration tab, Access Manager section, create or find the desired OAM Agent registration.

   2. On the agent registration page, submit values for POST data handling (Table 19-23):

      
      Name: DesiredAgent
      User-Defined Parameters

      	User-Defined Webgate Post Data Parameters with ECC	User-Defined Webgate Post Data Parameters with DCC
      	PostDataRestoration=true	PostDataRestoration=true

      
      

   3. Click Apply to submit the changes.

19.17.5 Testing POST Data Handling Configuration

The following actions can be performed in sequence to test your POST data handling configuration.

1. Complete all configurations as documented.

2. Develop a simple script to print the POST data and the URL protected by Webgate.

3. Use a browser to access the protected resource.

4. Provide credentials and establish SSO. Wait for the idle session timeout period.

5. With the same browser, use the form to post data to the same Webgate using the URL which can print the POST data. You will be redirected to credential collector.

6. Enter the same credentials previously used.

   From the HTTP headers you can see, after getting obrar.cgi from the credential collector, the protected resource Webgate will give a 200 response (previously it was 302) and the POST data can be printed by your script.

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

Table 19-42 identifies Long URL handling functionality with both the ECC and DCC.

19.18.2 About Configuring Long URL Handling

Table 19-43 summarizes the authentication schemes that support authentication Long URL handling.

Table 19-44 summarizes the parameters and complete configuration requirements for authentication Long URL handling. All requirements described in Table 19-44 are supported end to end with the authentication schemes in Table 19-43.

Long URL handling is enabled by default. The Webgate/credential collector sends data either as a query string or a POST. The length of the querystring parameter sent with obrareq.cgi and obrar.cgi is 2000 characters maximum.

19.20.1 Understanding the Adaptive Authentication Service

The following sections contain specific details on the Adaptive Authentication Service.

• Understanding the One Time Password Flow

• Generating a Secret Key

• Understanding Adaptive Authentication Configurations

19.20.2 Configuring Access Manager for Two-Factor Authentication

The following sections contain details on two-factor authentication configurations using the Administration Console. They assume that Access Manager 11gR2PS2, a WebGate and the Oracle HTTP Server (OHS) are installed and configured.

• Configuring OAuth for the Oracle Mobile Authenticator

• Configuring OAuth for the Google Authenticator

• Configuring Access Manager