22.9 Managing Authentication Schemes

Access to a resource or group of resources can be governed by a single authentication process known as an authentication scheme. An authentication scheme is a named component that defines the challenge mechanism required to authenticate a user.

Each authentication scheme must also include a defined authentication module (standard or custom, as described in "Deploying and Managing Individual Plug-ins for Authentication").

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

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

This section is divided into the following topics:

22.9.1 Authentication Schemes and Pages

All authentication schemes include the same elements with differing values.

Figure 22-26 shows the default LDAPScheme page as an example.

Figure 22-26 Default LDAPScheme Page

Description of Figure 22-26 follows
Description of "Figure 22-26 Default LDAPScheme Page"

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

Table 22-20 Authentication Scheme Definition

Element Description

Name

The unique name for this scheme, which appears in the navigation tree.

See Also:"Pre-configured Authentication Schemes"

Description

The optional description, up to 200 characters, that explains the use of this scheme.

Authentication Level

The trust level of the authentication scheme. This reflects the challenge method and degree of trust used to protect transport of credentials from the user.

The trust level is expressed as an integer value between 0 (no trust) and 99 (highest level of trust).

Note: Level 0 is unprotected. Only unprotected resources can be added to an Authentication Policy that uses an authentication scheme at protection level 0. For more information, see Table 25-1.

Note: After a user is authenticated for a resource at a specified level, the user is automatically authenticated for other resources in the same Application Domain or in different Application Domains, if the resources have the same or a lower trust level as the original resource.

See Also: "About Multi-Level and Step-Up Authentication".

Default

A non-editable box that is checked when the Set as Default button is clicked.

Challenge Method

One challenge method must be selected from those listed as available:

  • Form

  • Basic (LDAP)

  • X509 (Certificate)

  • WNA (Windows Native Authentication)

  • None

  • DAP

  • OAM10g

See Also: "Credential Challenge Methods"

Challenge Redirect URL

This URL declares the end point referencing the Credential Collector (ECC or DCC). For example:

ECC: /oam/server

DCC: http://<dcc-host:port>/

See Also:

Authentication Module

Identifies the pre-configured authentication module to be used to challenge the user for credentials. The module or plug-in specified here identifies the exact user identity store to be used.

  • FederationMTPlugin

  • FederationPlugin

  • Kerberos Plugin (Authentication Modules and Custom Authentication Module)

  • MTLDAPBasic

  • MTLDAPPlugin

  • OIFMTLDAPPlugin

  • Password Policy Validation Module

  • TAPModule

  • X509 Plugin (under the X509 Authentication Modules node)

See Also "Managing Native Authentication Modules" and "Orchestrating Multi-Step Authentication with Plug-in Based Modules".

Challenge URL

This URL is associated with the designated Challenge Method (FORM, for instance).

FORM-based, out of the box authentication scheme (LDAPScheme and LDAPNoPasswordValidationScheme), Challenge URL is "/pages/login.jsp". The context type and context values are used to build the final URL.

X509-based Challenge URL takes the form: https://managed_server_host:managed_server_ssl_port/oam/CredCollectServlet/X509

Note: The default Challenge URL is based on the credential collector embedded with the OAM Server (ECC). If you are using detached credential collector-enabled Webgate and related DCC pages installed with WebGate, see Configuring 11g WebGate and Authentication Policy for DCC.

Challenge Parameters

Supported challenge parameters are discussed in "Challenge Parameters for Authentication Schemes".

For schemes using Challenge Method FORM, X509, or DAP

Only Schemes with the Challenge Method of FORM, X509, or DAP include the following additional elements. Other schemes use defaults that require no change.

Context Type

Used to build the final URL for the Embedded Credential Collector (ECC only, DCC does not use this) based on the following possible values:

  • default: The Context Value is used to construct the final URL to forward to for credential collection. For example: with a challenge URL of "/pages/login.jsp" and a context value of /oam, the server forwards to "/oam/pages/login.jsp" for credential collection by the ECC.

  • customWar: If a customized credential collector page "customlogin.jsp" is deployed in a WAR file (with context root, "custom") within the same domain, it should be used to collect credentials. Then set the following values to have server forward to the WEB application page "/custom/customlogin.jsp" to collect credentials:

    • challenge_url = "/customlogin.jsp"
    • contextType="customWar"
    • contextValue="/contextroot of custom application"

  • customHtml: A custom html credential collector page. This file can be placed in a location that is accessible to the application. Set the following values to have the server forward to the custom servlet provided to read the html file and render the page:

    • challenge_url = "/CustomReadServlet"
    • contextType="customHtml"
    • contextValue="html file location"

  • external: If the login page is external, the file can be placed in a location that is accessible to the application. Set the following values to have the server redirect to the challenge URL (the fully-qualified URL of the external credential collector page) for credential collection. The username and password are collected by the external form (HTML or jsp) and submitted to the OAM Server:

    • challenge_url = "http://host:port/externallogin.jsp"
    • contextType="external"
    • contextValue=Not applicable

    See Also: "About Custom Login Pages" and Managing Global Password Policy

Context Value

Used to build the final URL for the credential collector. The default value is /oam.

About Custom Login Pages

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

See Also:

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

22.9.1.1 Pre-configured Authentication Schemes

Pre-configured Authentication Schemes such as BasicFAScheme and KerberosScheme are available with Access Manager.

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

Table 22-21 Pre-configured Authentication Schemes

Scheme Name Specifications Purpose

AnonymousScheme
  • Authentication Level: 0
  • Challenge Method: None
  • Authentication Module: AnonymousModule

Leaves unprotected specific Access Manager URLs and allows users to access such URLs without a challenge. Users are not challenged and do not need to enter their credentials.

Note: Authentication Level 0 is for public pages. Oracle recommends that you do not use Level: 0 in a custom authentication scheme.

Also: When a resource is protected by AnonymousScheme, it is not displayed in a session search.

BasicFAScheme

Only for Oracle Fusion Applications

For Fusion Applications

For specific information about this authentication scheme, refer to the Oracle Fusion Applications Technology Library located on the Oracle Technology Network (OTN) web site:

http://www.oracle.com/technetwork

BasicScheme
  • Authentication Level: 1
  • Challenge Method: Basic
  • Authentication Module: LDAP

Protects Access Manager-related resources (URLs) for most directory types.

Note: Authentication Level 1 is only one step higher than 0 public pages. Oracle recommends that you do not use Level: 1 in a custom authentication scheme.

BasicSessionlessScheme
  • Authentication Level: 1
  • Challenge Method: Basic
  • Authentication Module: LDAP

Primarily used for clients that don't support URL redirect or cookies.

Challenge Parameters: CookieLessMode=true

Note: Authentication Level 1 is only one step higher than 0 public pages. Oracle recommends that you do not use Level: 1 in a custom authentication scheme.

FAAuthScheme

Only for Oracle Fusion Applications
  • Authentication Level: 2
  • Challenge Method: FORM
  • Authentication Module: LDAP
  • Context: customWar
  • Context Value: /fusion_apps

For specific information about this authentication scheme, refer to the Oracle Fusion Applications Technology Library located on the Oracle Technology Network (OTN) web site:

http://www.oracle.com/technetwork

FederationMTScheme

Only for Oracle Fusion Applications
  • Authentication Level: 2
  • Challenge Method: FORM
  • Authentication Module: FederationMTPlugin
  • Context Type: customWar
  • Context Value: /fusion_apps
  • Challenge Parameters: initial_command=NONE
  • is_rsa=true

For specific information about this authentication scheme, refer to the Oracle Fusion Applications Technology Library located on the Oracle Technology Network (OTN) web site:

http://www.oracle.com/technetwork

See Also: "Challenge Parameters for Authentication Schemes".

FederationScheme

Only for Identity Federation 11.1.2.
  • Authentication Level: 2
  • Challenge Method: FORM
  • Authentication Module: FederationPlugin
  • Context Type: customWar
  • Context Value: /oam
  • Challenge Parameters: initial_command=NONE
  • is_rsa=true

See Also: Managing Oracle Access Management Identity Federation.

KerberosScheme
  • Authentication Level: 2
  • Challenge Method: WNA
  • Authentication Module: Kerberos
  • Context Type: customWar
  • Context Value: /fusion_apps

Protects Access Manager-related resources (URLs) for most directory types based on a Windows Native Authentication challenge method and valid WNA credentials in Active Directory.

LDAPNoPasswordValidationScheme
  • Authentication Level: 2
  • Challenge Method: FORM
  • Authentication Module: LDAPNoPasswordAuthModule
  • Context Type: default
  • Context Value: /oam

Note: LDAPNoPasswordAuthModule is similar to the DAP (asserter) mechanism.

See Also OAM10gScheme, later in this table.

Protects Access Manager-related resources (URLs) for most directory types based on a form challenge method.

Used with the Identity Asserter for SSO when you have resources in a WebLogic Container. See Securing Applications with Oracle Platform Security Services.

LDAPScheme
  • Authentication Level: 2
  • Challenge Method: FORM
  • Authentication Module: LDAP
  • Context Type: customWar
  • Context Value: /fusion_apps

Protects Access Manager-related resources (URLs) for most directory types based on a form challenge method.

OAAMAdvanced
  • Authentication Level: 2
  • Challenge Method: FORM
  • Authentication Module: LDAP
  • Context Type: external

Protects OAAM-related resources with an external context type. This authentication scheme is used when complete integration with OAAM is required. A Webgate must front ending the partner.

OAAMBasic
  • Authentication Level: 2
  • Challenge Method: FORM
  • Authentication Module: LDAP
  • Context Type: default
  • Context Value: /oam
  • Challenge Parameters
  • oaamPostAuth=true
  • oaamPreAuth=true

Protects OAAM-related resources with a default context type. This scheme should be used when basic integration with OAAM is required. Here, advanced features like OTP are not supported. This is more of an integration when mod_osso is used as the agent.

OAM10gScheme
  • Authentication Level: 2
  • Challenge Method: OAM10G
  • Authentication Module: LDAPNoPasswordAuthModule

See Also LDAPNoPasswordValidationScheme, earlier in this table.

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

Facilitates integration and coexistence with Oracle Access Manager 10g. In the coexistence mode, Oracle Access Manager 10g is the authenticator and Access Manager 11g is the asserter.

This scheme requires challenge mechanism OAM10G, specifically for OAM10g coexistence with OSSO as described in "OAM10G".

OAMAdminConsoleScheme
  • Authentication Level: 2
  • Challenge Method: FORM
  • Authentication Module: LDAP
  • Context Type: default
  • Context Value: /oam

Authentication scheme for Oracle Access Management Console.

OICScheme
  • Authentication Level: 2
  • Challenge Method: DAP
  • Authentication Module: TAPModule
  • Context Type: External
  • Challenge Parameters:
  • TAPPartnerId=RPPartner
  • MatchLDAPAttribute=mail

Access Manager uses this scheme to delegate authentication to Mobile and Social services and redirects the user to the Mobile and Social login page for authentication.

See Also: Managing Oracle Access Management Mobile and Social

OIFScheme

Only for Oracle Identity Federation 11.1.1.

For Identity Federation 11.1.2, use FederationScheme.
  • Authentication Level: 2
  • Challenge Method: DAP
  • Authentication Module: DAP
  • Context Type: External

This scheme delegates authentication to OIF, after which, Oracle Identity Federation sends back a token that is asserted by the OAM Server.

The Delegated Authentication Protocol (DAP) challenge method is used to delegate authentication to a third-party (OIF in this case).

Challenge Parameters: TAPPartnerId=OIFDAPPartner

See Also: "Challenge Parameters for Authentication Schemes".

OIMScheme
  • Authentication Level: 1
  • Challenge Method: FORM
  • Authentication Module: LDAP
  • Context Type: default
  • Context Value: /oam

Protects Oracle Identity Manager-related resources with a default context type.

Note: When integrating OAM and OIM, OAM downgrades the user's authentication level when any of the following is detected:

  • password expiry
  • forced password change
  • challenge setup not done

This enables the user to access the pages only after performing necessary operations in the identity management (OIM) page to which the user is redirected.

At Level 1, only public and OIM pages for the required operations can be accessed.

Note: Authentication Level 1 is only one step higher than 0 public pages. Oracle recommends that you do not use Level: 1 in a custom authentication scheme.
   

Set as the Default authentication scheme for environments that have been migrated from OSSO 10g to Access Manager 11g.

PasswordPolicyValidationScheme
  • Authentication Level: 2
  • Challenge Method: FORM
  • Authentication Module: Password Policy Validation Module
  • Context: External

Enables password policy evaluation.

TAPResponseOnlyScheme
  • Authentication Level: 2
  • Challenge Method: DAP
  • Authentication Module: DAP
  

TAPScheme
  • Authentication Level: 2
  • Challenge Method: DAP
  • Authentication Module: DAP
  • Context Type: External

To use TAPScheme for IDM product resources in the IAM Suite Application Domain, Protected Higher Level Policy, the following configuration must be done in addition to changing the Authentication Scheme.

  1. From the IAM Suite Application Domain, Protected Higher Level Policy, remove IAMSuiteAgent:/oamTAPAuthenticate.

  2. Create a new Authentication Policy in the IAM Suite Application Domain, that uses LDAPScheme.

  3. Protect IAMSuiteAgent:/oamTAPAuthenticate using the newly created policy.

Challenge Parameters: TAPPartnerId=TAPPartnerName

X509Scheme
  • Authentication Level: 5
  • Challenge Method: X509
  • Authentication Module: X509

This authentication scheme is a certificate-based user identification method. To use this method, a certificate must be installed on the user's browser and the Web server must be SSL-enabled.

Note: This scheme relies on SSL to deliver the use's X.509 certificate to the OAM Server.

22.9.1.2 Credential Challenge Methods

Authentication involves determining what credentials a user must supply when requesting access to a resource, gathering credentials over HTTP, and returning an HTTP response that is based on the results of credential validation.

Access Manager provides the following credential challenge methods for use in an authentication scheme:

FORM

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

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

Note:

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

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

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

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

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

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

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

BASIC

This built-in Web server challenge mechanism requires a user to enter her login ID and password. The credentials supplied are compared to the user's definition in the LDAP directory server. Thus, a Basic challenge relies on the LDAP Authentication Module and user identity store associated with that module.

Note:

If a URL is protected by Access Manager using Basic Authentication with OID configured as the identity store, OID defined users can not log in. To resolve this, add the following line before the closing </security-configuration> tag in the config.xml file.

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

X509

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

Note:

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

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

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

  • SubjectDN

  • SubjectUniqueID

  • Mail

  • CN

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

Note:

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

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

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

WNA

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

Note:

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

See Also:

Configuring Access Manager for Windows Native Authentication for details about integration with Windows Native Authentication

NONE

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

DAP

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

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

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

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

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

OAM10G

DOC: Create version 2 of this topic before making 12C specific changes here.

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

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

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

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

See Also:

22.9.1.3 Challenge Parameters for Authentication Schemes

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

The syntax for specifying any challenge parameter is:

<parmatername>=<value>

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

Table 22-22 identifies the pre-configured schemes with challenge parameters.

Table 22-22 Challenge Parameters in Pre-configured Schemes

Pre-configured Schemes Challenge Parameter

BasicSessionlessScheme

CookieLessMode=true

Primarily used for clients that do not support URL redirect or cookies.

FederationMTScheme
  • initial_command=NONE

Primarily used for Fusion Applications that support multiple factor authentication.

  • is_rsa=true

Used with RSA multi-step authentication, as described in Integrating RSA SecurID Authentication with Access Manager and the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

FederationScheme

For Identity Federation 11.1.2.only. Use OIFScheme for Oracle Identify Federation 11.1.1.

Primarily used for clients that do not support URL redirect or cookies.

  • Context Value: /fusion_apps
  • Challenge Parameters: initial_command=NONE
  • is_rsa=true

Primarily used for clients that do not support URL redirect or cookies.

OAAMBasic

oaamPostAuth=true

oaamPreAuth=true

Protects OAAM-related resources. These parameters should be used when basic integration with OAAM is required.

OIFScheme

For Oracle Identify Federation 11.1.1 only. Use FederationScheme for Identity Federation 11.1.2.

TAPPartnerId=OIFDAPPartner

This scheme delegates authentication to Oracle Identity Federation 11.1.1, after which, Federation sends back a token that is asserted by the OAM Server.

TapScheme

TAPPartnerId=TAPPartnerName

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

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

Challenge Parameter Definition

initial_command=NONE

Required to enable the plug-in to indicate which credentials are to be collected.

For example, for Form-based authentication, the framework typically expects to collect "username" and "password" (submitted from the login page). However, you might want credentials from different fields of the login page; "form_username" and "form_password" for example. Setting this challenge parameter shifts initial control from the login page to the plug-in, which decides the parameters to collect from the login page then appropriately forwards or redirects to the page.

Default: blank (not set)

action=

The actions parameter identifies the URL to which the HTML form is posting when you do not want to use the hard coded ECC default /oam/server/auth_cred_submit.

Note: ECC does not use the action= parameter. When the action= challenge parameter is not specified, both the DCC and ECC use the default: /oam/server/auth_cred_submit.

See Also: "Configuring the PasswordPolicyValidationScheme"

creds=

DCC Only

Supported by the detached credential collector (DCC) only.

In the following 11g example, username and password are the names of relevant fields in the login form:

creds=username password

NOTE: Format of this challenge parameter has changed since the 10g release.

The Web server source (server parameter) takes precedence over other sources. This prevents the request data, which is under control of the user, from overriding Web server data. For example, a remote_user cookie sent from a user will not override a remote_user variable set by the Web server

Generally, when the user submits a login form that is protected by an authentication scheme with a Form-based challenge method, the DCC processes the credentials that were specified with this creds= parameter.

For forms using METHOD=POST processing, the browser sends a POST request to the Web server with the credential data from the form in the body of the request. If the form uses METHOD=GET, the browser sends a GET request with query string parameters with the same names as those specified on the creds parameter. Oracle recommends that you use POST processing, if possible.

Note: You can specify the creds parameter with the other types of challenge methods. For a plug-in to make use of the creds parameter, you specify what is passed in the obMap credentials parameter of the ObUserSession object, as described in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

See Also: "Configuring the PasswordPolicyValidationScheme"

extracreds=

DCC Only

Supported by the DCC only. Specifies optional parameters which, if present, are made available to the authentication plug-in for collection during each iteration of a multi-step authentication using the DCC.

The extracreds parameter uses the same syntax as the creds parameter: extracreds= separated qualified or unqualified names [{any | cookie | header | server | query | post}:] <name>. However, the value any is used by extracreds only. For example:

extracreds=[{any | cookie | header | server | query | post}:] <name>

See Also: "Configuring the PasswordPolicyValidationScheme"

OverrideRetryLimit=0

The number of tries that can override the RetryLimit for login.

The value must be a positive integer.

A value of zero (0) disables this function.

See Also: "Configuring the PasswordPolicyValidationScheme"

ChallengeRedirectMethod

Authentication POST data preservation parameter for both the embedded credential collector (ECC) and the detached credential collector (DCC).

Value: GET|POST|DYNAMIC

Note: Preference is given first to the Authentication Scheme containing this parameter; second to the Webgate providing this user defined parameter. Otherwise, default behavior is Dynamic.

See Also: "Configuring Authentication POST Data Handling"

Table 15-2

MaxPreservedPostDataBytes

Configure this Authentication Scheme challenge parameter (or user-defined Webgate parameter) for authentication POST-data preservation.

Default: 8192 bytes

Note: Preference is given first to the Authentication Scheme containing this parameter; second to the Webgate providing this user-defined parameter. Otherwise, default behavior is 8192 bytes.

This parameter defines the maximum length of POST data that Webgate can preserve. If the size of inbound raw user POST data (or encrypted post data after processing), crosses this limit, POST data is dropped and the existing authentication flow continues. The event is logged as usual.

See Also: "Configuring Authentication POST Data Handling"

Table 15-2

MaxPostDataBytes=

DCC Only

Configure this Authentication Scheme challenge parameter to restrict the maximum number of bytes of POST data that is submitted as user credentials and sent to the OAM Server.

Configure this challenge parameter for POST-data preservation by the DCC only to limit the maximum size of the POST data that can be posted as credentials on the form and sent to the OAM Server. DCC compares the value of the content-length header with the limit set.

Default: 8192 bytes

This challenge parameter requires a positive integer value.

See Also:

Table 15-2

"Configuring the PasswordPolicyValidationScheme"

"Configuring Authentication POST Data Handling"

ssoCookie=

Controls the OAMAuthnCookie cookie, as described in "Configuring Challenge Parameters for Encrypted Cookies".

Default:

ssoCookie=httponly

ssoCookie=Secure

Disable either setting:

ssoCookie=disablehttponly

ssoCookie=disableSecure

Note: These parameters are configured differently depending on your credential collector configuration.

  • For detached credential collector-enabled 11g Webgates, set these parameters directly in the agent registration page.

  • For non-DCC agents (Resource Webgates), these parameters are configured through user-defined challenge parameters in authentication schemes.

See Also:

Table 22-30

miscCookies=

Controls other miscellaneous Access Manager internal cookies. By default, httponly is enabled for all other (miscellaneous) cookies.

Default:

miscCookies=httponly

miscCookies=Secure

Disable either setting:

miscCookies=disablehttponly

miscCookies=disableSecure

Note: These parameters are configured differently depending on your credential collector configuration.

  • For detached credential collector-enabled Webgates, set these parameters directly in the agent registration page.

  • For non-DCC agents (Resource Webgates), these parameters are configured through challenge parameters of the same name.

See Also:

Table 22-30

"Configuring the PasswordPolicyValidationScheme"

DCCCtxCookieMaxLength=

DCC Only

Defines the maximum length of the DCC cookie.

Default: 4096

See Also: TempStateMode in this table for more information.

TempStateMode=

Controls how the DCC stores the OAM Server state (cookie or form) as specified with the parameter's value:

  • form: This is the default, and is required for retaining authentication POST data. The OAM Server state stored and passed through the form parameter "OAM_REQ", to avoid the case when the OAM Server configuration serverRequestCacheType=COOKIE, bloated server state causes DCCCtxCookie to explode beyond limit resulting in incorrect behavior.

    The cookie cache mode can be changed to FORM mode from default COOKIE mode. FORM mode works with long URLs. The only difference in behavior is for programmatic authentication, which requires a proper form Submit to pass the OAM_REQ parameter set to the form. Custom credential collection pages need to handle the OAM_REQ parameter that is submitted with the form.

  • cookie: Adding this parameter and value stores the OAM Server state through part of the DCCCtxCookie (encdata=… svrctx=…). However, when serverRequestCacheType=COOKIE or =FORM, this could cause incorrect behavior if the resulting cookie length is beyond browser limit.

Note:

  • When serverRequestCacheType=COOKIE, Oracle recommends TempStateMode=form.

  • When serverRequestCacheType=BASIC, either mode is fine.

To update serverRequestCacheType, use the WLST command configRequestCacheType as described in the WLST Command Reference for WebLogic Server. Editing serverRequestCacheType is not supported using the Oracle Access Management Console.

With ECC: The serverRequestCacheType dictates whether OAM Server stores its state in memory(BASIC) or not (FORM or COOKIE). serverRequestCacheType = COOKIE or FORM only makes difference when ECC is used. OAM Server stores its state in a request token, which ECC keeps in a cookie or hidden form field as specified with the parameter: serverRequestCacheType=COOKIE, for example.

With DCC: There is no difference between serverRequestCacheType=COOKIE or FORM. TempStateMode controls how the DCC stores the OAM Server state (cookie or form) as specified with the parameter's value: TempStateMode=cookie, for example. With the DCC, POST data restoration with a Form-based Authentication Scheme requires the challenge parameter TempStateMode=form.

See Also:

allowedAccessGateList=

Authentication Scheme challenge parameter configured with SPACE separated list of WebGate IDs defining those WebGates that are allowed to enforce authentication by this scheme. For example:

allowedAccessGateList=WebgateID1 WebgateID2

TunneledUrls

  • For OAM : TunneledUrls=/oam

  • For OAAM : TunneledUrls=/oam/server/obrareq.cgi,/oam/server/dap/cred_submit

  • For OIF : TunneledUrls=/oamfed

  • For OIM : TunneledUrls=/oam

22.9.2 Understanding Multi-Level and Step-Up Authentication

This section provides the following topics:

22.9.2.1 About Multi-Level and Step-Up Authentication

Every authentication scheme requires a strength level. The higher the number, the more more secure the authentication mechanism; the lower the number, the less stringent the scheme.

For example:

  • LDAPScheme authLevel=1

  • KerbScheme authLevel=3

Note:

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

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

Note:

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

Access Manager policies allow different resources of the same application to be protected with different authentication levels.

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

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

Registered agents detect the authentication level as follows:

See Also:

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

22.9.2.2 Detection of Insufficient Authentication Level by OAM Agent

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

See Also:

"Understanding Authentication Methods and Credential Collectors"

Process overview: OAM Agent detects insufficient session level

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

Note:

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

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

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

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

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

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

    • If sufficient, the access is granted access.

22.9.2.3 Changing Security Level of an Authentication Scheme during the Authentication Process

You can write a custom plug-in to change the security level of an authentication scheme during the authentication process.

In some cases, you may want to increase the security level of an authentication scheme during the authentication process depending on certain conditions. You may want the security level of an authentication scheme to depend on the application the user logged in from. For example, Active Directory and a reverse proxy are among the sources your users can log in from. During the authentication process, you may want to dynamically set one authentication security level to be used for users who log in from Active Directory and another security level to be used for users who log in from the reverse proxy.

Enable custom authentication plug-ins to set the authentication level as a plug-in response. Write a new custom authentication plug-in where a configurable authentication level is set as a plug-in step parameter in the plug-in response. For example, PLUGIN_AUTHN_LEVEL is configured in the plug-in response. It helps set the authentication level dynamically based on the authentication mechanism used.

To avoid any security implications resulting from the custom plug-in, use an optional authentication scheme challenge parameter, MAX_AUTHN_LEVEL. The value of MAX_AUTHN_LEVEL is the maximum authentication level that can be set by a custom authentication plug-in protecting resources. In the custom authentication scheme, this parameter is disabled by default. You need to set this mandatory parameter with a higher value than the PLUGIN_AUTHN_LEVEL for the plug-in to dynamically change the value of authentication level during the authentication process.

Write a custom authentication plug-in and configure KEY_AUTHN_LEVEL with a value lower than MAX_AUTHN_LEVEL. Create a custom authentication module that uses the new authentication plug-in and associate it with the Custom Authentication Scheme. Specify the Scheme in Authentication policy protecting the resource. When the user session is created, warning message about the plug-in overriding the maximum authentication value set by the administrator is logged by OAM server. When MAX_AUTHN_LEVEL is not configured or the plug-in tries to set value greater than MAX_AUTHN_LEVEL, the authentication succeeds with the authentication level set in the authentication scheme.

Following is the sample code to set authentication level as a plug-in response:

String stepName = context.getStringAttribute(PluginConstants.KEY_STEP_NAME);
String pluginLevel = PlugInUtil.getFlowParam(stepName, " PLUGIN_AUTH_LEVEL ", context);
PluginResponse rsp = new PluginResponse();
rsp.setName(PluginConstants.KEY_AUTHN_LEVEL);
rsp.setType(PluginAttributeContextType.LITERAL);
rsp.setValue(pluginLevel);
context.addResponse(rsp);

22.9.2.4 Multi-Level Authentication Processing with 10g OSSO Agent

In contrast to OAM Agents, all the resources protected by mod_osso on a host (or virtual host) are protected at the same level. With mod_osso, multi-level authentication applies when user is already authenticated using one mod_osso host (or virtual host) at Level 2 and then tries to access another mod_osso protected host (or virtual host) at level 3.

Process overview: OSSO Agent multi-level authentication flow

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

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

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

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

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

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

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

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

22.9.3 Creating an Authentication Scheme

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

Prerequisites

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

See Also:

  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. Click the Create Authentication Scheme.

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

    8. Context Type

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

  6. Dismiss the Confirmation window.

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

  8. Confirm the new scheme appears in the list of schemes (refresh if needed).

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

22.9.4 Searching for an Authentication Scheme

Users with valid Administrator credentials can search for a specific authentication scheme.

See Also:

"SSO Agent Search Page"

  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 Name field, enter the target scheme name (with or without wild card *). For example: 
    OA*
  4. Click the Search button to initiate the search.
  5. Click the Search Results tab to display the results table, and then:

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

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

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

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

22.9.5 Viewing, Editing, or Deleting an Authentication Scheme

Users with valid Administrator credentials can view or modify an existing authentication scheme.

Note:

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

See Also:

  1. Search for the target scheme, as described in the previous section.

  2. In the list of search results, select the target scheme and click Edit.

  3. Edit:

    1. On the Authentication Scheme page, modify values for your environment (Table 22-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.

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

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