24.7 Configuring Password Policy Authentication

After preparing your password policy, Default Store, and Administrator, you can develop your authentication module and scheme.

• Password Policy Validation Authentication Module

• Configuring the PasswordPolicyValidationScheme

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

• Supporting DCC Authentication Schemes with Pre-Authentication Rules

24.7.1 Password Policy Validation Authentication Module

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

Note:

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

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

Note:

UserPasswordPolicyPlugin is supported only when using LDAP based authentication modules. It does not work with non LDAP authentication modules.

Figure 24-2 Password Policy Validation Authentication Module with Orchestrated Plug-ins

Description of "Figure 24-2 Password Policy Validation Authentication Module with Orchestrated Plug-ins"

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

See Also:

"Orchestrating Multi-Step Authentication with Plug-in Based Modules".

Figure 24-3 shows the orchestration of steps within the authentication module. For more information on modules and steps, see "Pre-populated Plug-ins for Configuring Access Manager with Multi-Step Authentication".

Figure 24-3 Step Orchestration for Password Policy Validation Module

Description of "Figure 24-3 Step Orchestration for Password Policy Validation Module"

Table 24-8 describes the Password Policy Validation module step details that you specify.

Table 24-8 User Password Step Details

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

Prerequisites

Defining Your Global Password Policy

Note:

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

1. In the Oracle Access Management Console, click Application Security at the top of the window.

2. In the Application Security console, click Authentication Modules. in the Plug-ins section.

3. In the Authentication Modules page, click Search, then click Password Policy Authentication Module.

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

5. Click Apply.

6. Proceed to "Configuring the PasswordPolicyValidationScheme".

24.7.2 Configuring the PasswordPolicyValidationScheme

Users with Administrator credentials can configure the PasswordPolicyValidationScheme.

You can have multiple authentication schemes for use with the global password policy.

Note:

Differences between values for the ECC versus the DCC include (Table 24-3):

• Challenge Redirect URL: Credential Collector host and port

• Challenge URL: Credential Collector Pages

• Challenge Parameters: Table 22-22

Prerequisites

Password Policy Validation Authentication Module

See Also:

"Managing Authentication Schemes"

1. In the Oracle Access Management Console, click Application Security at the top of the window.
2. In the Application Security console, click Authentication Schemes in the Access Manager section.
3. In the Search Authentication Schemes page, click Search, then click PasswordPolicyValidationScheme.
4. 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 22-23 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

5. Click Apply.
6. Proceed to "Adding Your PasswordPolicyValidationScheme to ECC Authentication Policy".

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

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

   See Also:

   "Adding Your PasswordPolicyValidationScheme to ECC Authentication Policy"

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 (Managing Policies to Protect Resources and Enable SSO).

3. Proceed as needed for your environment:

   • ECC: Completing Password Policy Configuration

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

24.7.4 Supporting DCC Authentication Schemes with Pre-Authentication Rules

When DCC authentication schemes are used, pre-authentication rules are unable to distinguish between internal and external URLs from different proxies. You have to create a new pre-authentication rule using returnHost parameter to support DCC authentication schemes.

Pre-authentication rules allow you to define a policy that can either block access to the user or allow OAM to use a different authentication scheme based on certain conditions.

The host parameter in the request data allows pre-authentication rules to be executed against the host name of a protected resource. When the request is originating from a DCC WebGate, the host parameter is unable to distinguish between internal and external URLs from different proxies. If you want the DCC WebGate to work with the proxy, you have to create a new pre-authentication rule as follows:

request.returnHost.lower().find('<proxy_host_name>')>0

The returnHost parameter has the proxy host name for internal and external URLs irrespective of whether the request is originated from a ECC or DCC WebGate. When you access the resource through the specified proxy, the authentication scheme is switched as specified in the new pre-authentication rule. In case of other configured proxy, the original authentication scheme specified in the Authentication Policy tab is retained.