22.5 Understanding Authentication Methods and Credential Collectors

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

This section provides the following topics:

22.5.1 Authentication Methods Supported by Access Manager

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 "Simple Form Versus Multi-Factor (Multi-Step) Authentication".

Windows Native Authentication

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

Other Authentication Types

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

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

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

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

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

Note:

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

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

22.5.2 Embedded Credential Collector Versus Detached Credential Collector

Access Manager 11.1.2 supports the embedded credential collector (ECC) by default but 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 ECC. The centralized DCC presents the login page, collects the 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.

Note:

The DCC is the recommended approach for credential collection. See Understanding Credential Collection and Login for more details.

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

Table 22-5 Comparing the DCC and ECC

Feature DCC ECC

Deployment

The Detached Credential Collector remains a logical part of the server and acts as a front channel communication endpoint of the OAM Server. However, the DCC also:

  • Stands alone (detached from the OAM Server and does not require an application server).

  • Supports RSA SecurID passcode verification, get next token, create new pin workflows.

  • Authenticates Webgate with greater flexibility for server scale-out and attack resilience as well as credential collection UI construction, flow, and lifecycle management.

The Embedded Credential Collector is deployed with, and integral to, the OAM Server and part of the protocol binding layer.

The ECC supports RSA SecurID passcode verification, get next token, create new pin workflows.

DMZ Deployment

Yes.

The main benefit of a deployment using DCC in the DMZ is the termination of the end-user network connections within the public network, and the use of Oracle Access Protocol (Oracle's proprietary application network protocol) over mutually authenticated connections reaching the OAM Server. This offers a complete isolation of the OAM Server from the establishment of any unauthenticated network connection.

Unauthenticated users cannot send malformed requests to the OAM Server.

No.

Communication channel

DCC consumes HTTP/HTTPS requests from the user, then communicates with the OAM Server across the Oracle Access Protocol (back channel), which can be SSL-enabled.

ECC communicates with both the user and the OAM Server across HTTP/HTTPS.

DCC login, error, and password pages

Dynamic pages general login/logout and password policy with the DCC are excluded automatically through the OHS httpd.conf/webgate.conf file--you do not need to configure a policy to exclude these. See the Webgate host in $WEBGATE_HOME/webgate/ohs/oamsso/*, $WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl, and $WEBGATE_HOME/webgate/ohs/oamsso-bin/templates/* directory:

  • Login page: /oamsso-bin/login.pl

  • Logout: /oamsso-bin/logout.pl

  • RSA SecurID login pages: /oamsso-bin/securid.pl

Note: Update the Perl location in the first line of the login, logout, and securid scripts in /oamsso-bin.

See Also:

Pages where the user enters her credentials arrive out of the box on the OAM Server and require no additional settings or changes.

  • Login page: /pages/login.jsp

  • Logout page: /pages/logout.jsp

  • Error page: /pages/servererror.jsp

  • Multi-step: /pages/mfa_login.jsp

Perl Scripts for DCC-based Login and Logout

Perl Scripts for DCC-based Login and Logout

The path name of the Perl executable must be updated in Oracle-provided Perl scripts on the Webgate host $WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl to be consistent with the actual location.

Unix: The which command finds Perl on the OAM Server. For example:

which perl
/usr/bin/perl

However, Perl scripts themselves point to:

/usr/local/bin/perl

Windows: The default Perl Interpreter specified in Oracle-provided Perl scripts will not be available. You must update the Perl Interpreter path in these scripts to actual path to Perl on your system.

N/A

Password policy enforcement

Yes.

See Configuring 11g WebGate and Authentication Policy for DCC

Yes

See: Managing Global Password Policy

Authentication scheme collection methods

DCC supports only Form Based Authentication.

ECC supports all challenge methods.

The ECC collects user credentials based on the challenge method of the Authentication Scheme and sends it back to OAM Server for validation.

Custom Authentication Plug-ins and Challenge Methods

Yes; same as ECC.

All challenge methods and multi-step authentication (Password Policy and other custom authentication plugins) are supported.

Single Step (Simple Form) Authentication

Yes; same as ECC.

Yes. Both the DCC and ECC handle this, where:

  • All credentials are supplied in one simple form

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

  • This can be retried upon failure

Multi-Step Authentication

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

In this case:

  • Not all required credentials are supplied at once

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

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

  • The Authentication plug-in can have multiple steps configured

See "Understanding Multi-Level and Step-Up Authentication"

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

Authentication Processing

The DCC does not restrict authentication functionality of the OAM Server in any way as compared to the ECC.

The DCC:

  1. Handles authentication redirects from 11g Webgates.

  2. Handles Form-based authentication, which consists of a challenge to the user for their credentials (simple form or multi-factor).

  3. Decrypts the authentication request message from the agent using the agent key; performs basic integrity checks; validates request time; and extracts all parameters from the request including request context.

  4. Constructs the authentication response message, including request context originally retrieved, encrypts obrar using the agent key.

  5. Decrypts the logout redirect request using the agent key to trigger logout processing.

During authentication:

  1. The ECC handles the request coming to the protocol binding layer (PBL), which converts it and sends it to the SSO Engine.

  2. The SSO Engine checks for a valid session and, if none, transfers control to the Authentication Engine.

  3. The Authentication Engine checks for resource protection and fetches the authentication scheme associated with the resource.

  4. The ECC interacts with the client, accepts the data, and submits this to the PBL.

Overriding the ECC

To deploy the DCC and override the ECC, an Administrator must perform the following tasks to specify the relevant DCC URLs and forms.

  • OAM Agent registration: Allow Credential Collector Operations (enable for DCC)

  • Authentication Module, Step Orchestration: Error (if Failure)

  • Authentication Scheme: Challenge Redirect URL (DCC host and port)

  • Authentication Scheme: Challenge URL /oamsso-bin/login.pl (DCC login pages)

  • Authentication Scheme: Challenge Method

  • Password Policy: Password Service URL for DCC (Default: /oamsso-bin/login.pl)

See Configuring 11g WebGate and Authentication Policy for DCC

N/A

Logout Configuration

See "Configuring Logout When Using Detached Credential Collector-Enabled WebGate"

See "Configuring Centralized Logout for 11g WebGates"

Cookie/Token

  • DCCCtxCookie

  • 11g WebGate: OAMAuthnCookie

  • 11g WebGate: OAMRequestContext

See: "Single Sign-On Cookies During User Login"

  • 11g Webgate: OAMAuthnCookie

  • 11g Webgate: OAM_REQ

  • 11g Webgate: OAM_ID

  • 11g Webgate: OAMRequestContext

See: "Single Sign-On Cookies During User Login"

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