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:
All authentication schemes include the same elements with differing values.
Figure 22-26 shows the default LDAPScheme page as an example.
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:
See Also: "Credential Challenge Methods" |
Challenge Redirect URL |
This URL declares the end point referencing the Credential Collector (ECC or DCC). For example: ECC: DCC: 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.
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: 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:
|
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.
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 |
|
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: |
BasicScheme |
|
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 |
|
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 |
|
For specific information about this authentication scheme, refer to the Oracle Fusion Applications Technology Library located on the Oracle Technology Network (OTN) web site: |
FederationMTScheme Only for Oracle 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:
See Also: "Challenge Parameters for Authentication Schemes". |
FederationScheme Only for Identity Federation 11.1.2. |
|
See Also: Managing Oracle Access Management Identity Federation. |
KerberosScheme |
|
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 |
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 |
|
Protects Access Manager-related resources (URLs) for most directory types based on a form challenge method. |
OAAMAdvanced |
|
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 |
|
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 |
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 scheme for Oracle Access Management Console. |
OICScheme |
|
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. |
|
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 |
|
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:
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 |
|
Enables password policy evaluation. |
TAPResponseOnlyScheme |
|
|
TAPScheme |
|
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.
Challenge Parameters: TAPPartnerId=TAPPartnerName |
X509Scheme |
|
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. |
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
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:
OAM10gScheme in Table 22-21
enableCoexistMode
and disableCoexistMode
in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference
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 |
Primarily used for Fusion Applications that support multiple factor authentication.
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.
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 Note: ECC does not use the 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 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 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=[{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" |
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" |
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: |
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.
See Also: |
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.
See Also: |
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:
Note:
To update 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 |
|
This section provides the following topics:
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:
OAM Agents receive an insufficient level error message from the OAM Server, as described in "Detection of Insufficient Authentication Level by OAM Agent".
mod_osso detects the authentication level from dynamic directives, as described in Multi-Level Authentication Processing with 10g OSSO Agent.
Note:
mod_osso delegates authentication to Access Manager. Oracle recommends that mod_osso-protected resources be protected with Access Manager authentication levels. the mod_osso plug-in does not support two resources on the same application with a different trust level.
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.
When the user requests a resource that is protected with a higher level authentication scheme, the following process occurs.
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.
The OAM Agent sends the request to the OAM Proxy to obtain the scheme details for the protected resource.
The OAM Agent sends the request for session information to the OAM Proxy.
The OAM Proxy returns details of the ObSSOCookie, including the authenticated level of the ObSSOCookie.
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.
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);
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
The user tries to access a resource protected by mod_osso on host1 at level 2.
The OSSO Agent sends the request to the OAM Proxy to obtain the authentication scheme details for the protected resource.
The OAM_ID cookie for SSO Server and a host based cookie "HOST_port" for host1 are set and contain authentication level information.
After authentication, the user tries to access a resource on host2 that is protected with a higher level of authentication.
The user is redirected to the OAM Server for authentication because this is the first time accessing host2.
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.
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:
In the Oracle Access Management Console, click Application Security at the top of the window.
In the Application Security Console, click Authentication Schemes in the Access Manager section.
Click the Create Authentication Scheme.
Fill in the fresh Authentication Scheme page (Table 22-20) by supplying information based on your deployment:
Name: LDAPSimpleFormScheme
Authentication Level
Challenge Method: FORM
Challenge Redirect URL: http://CredentialCollectorhost:port
Authentication Module: LDAP
Challenge URL: /CredentialCollector/loginform...
Challenge Parameters: Table 22-22, Table 22-23, Table 22-30
Context Type
Click Apply to submit the new scheme (or close the page without applying changes).
Dismiss the Confirmation window.
Optional: Click the Set as Default button to automatically use this with new Application Domains, then close the Confirmation window.
Confirm the new scheme appears in the list of schemes (refresh if needed).
Proceed to "Defining Authentication Policies for Specific Resources".
Users with valid Administrator credentials can search for a specific authentication scheme.
See Also:
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.
Search for the target scheme, as described in the previous section.
In the list of search results, select the target scheme and click Edit.
Edit:
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.
Click Apply to submit the changes (or close the page without applying changes).
Dismiss the Confirmation window.
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.
Delete:
Review any Application Domain using this authentication scheme and assign a different scheme.
Review the Authentication Scheme page to confirm this is the scheme to remove, then close the page.
In the navigation tree, click the name of the scheme and then click the Delete button in the tool bar.
Confirm removal (or dismiss the Confirmation window).