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:
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".
See Also:
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 both OSSO and 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".
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.
See Also:
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:
|
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 $
Note: Update the Perl location in the first line of the login, logout, and securid scripts in 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.
|
|
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 Unix: The 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 |
|
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:
|
|
Multi-Step Authentication |
Yes. Both the DCC and ECC handle complex multi-factor (multi-step, iterative, and variable) Authentication processing. In this case:
|
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:
|
During authentication:
|
|
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.
See Configuring 11g WebGate and Authentication Policy for DCC |
N/A |
|
Logout Configuration |
See "Configuring Logout When Using Detached Credential Collector-Enabled WebGate" |
|
|
Cookie/Token |
|
|
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.