22.6 Managing Native Authentication Modules

In Access Manager, each authentication scheme requires an authentication module.

Native authentication modules lack the flexibility to orchestrate two or more plug-ins to meet specialized authentication needs. Therefore, native authentication modules are targeted for deprecation in future releases. Oracle strongly recommends using plug-in based authentication modules as described "Orchestrating Multi-Step Authentication with Plug-in Based Modules".

This section provides the following information:

22.6.1 Native Access Manager Authentication Modules

Native Access Manager Authentication Modules include LDAP, LDAPNoPasswordAuthModule, Kerberos, X509, and, Custom Authentication Modules.

"Table 22-6" lists the Native Access Manager Authentication Modules and description.

Table 22-6 Native Authentication Modules

Module Name	Description
LDAP	Matches the credentials (username and password) of the user who requests a resource to a user definition stored in an LDAP directory server. An LDAP module is required for Basic and Form challenge methods. See Also: "Native LDAP Authentication Modules".
LDAPNoPasswordAuthModule	Matches the credentials (username and password) of the user who requests a resource to a user definition stored in an LDAP directory server. An LDAP module is required for Basic and Form challenge methods. See Also: "Native LDAP Authentication Modules".
Kerberos	Identifies the key tab file and krb5.configuration file names and Principal. Use this plug-in when configuring Access Manager for Windows Native Authentication, as described in Configuring Access Manager for Windows Native Authentication. See Also: "Native Kerberos Authentication Module".
X509	Similar to the LDAPPlugin with additional properties that indicate which attribute of the client's X.509 certificate should be validated against the user attribute in LDAP. See Also: "Native X.509 Authentication Module".
Custom Authentication Modules	This type of module relies on bundled plug-ins (or those that are developed using the Access Manager Authentication Extensibility Java API). This type of module generally uses more than one plug-in that you can orchestrate to ensure that each one performs a specific authentication function. Depending on the success or failure action defined for each plug-in, another authentication plug-in is called. See Also: "Pre-populated Plug-ins for Configuring Access Manager with Multi-Step Authentication", and Oracle Fusion Middleware Developer's Guide for Oracle Access Management for details about developing and deploying plug-ins, custom authentication modules, and schemes that use custom modules.

22.6.1.1 Native Kerberos Authentication Module

The pre-configured Kerberos authentication module is illustrated in Figure 22-5. Additional details follow the figure.

Figure 22-5 Native Kerberos Authentication Module

Description of "Figure 22-5 Native Kerberos Authentication Module"

Table 22-7 describes the definition of the native Kerberos authentication module. You can use the existing, pre-configured Kerberos authentication module or create one of your own.

Table 22-7 Native Kerberos Authentication Module Definition

Element	Description
Name	The unique ID of this module, which can include upper and lower case alpha characters as well as numbers and spaces.
Key Tab File	The path to the encrypted, local, on-disk copy of the host's key, required to authenticate to the key distribution center (KDC). For example: /etc/krb5.keytab. The KDC authenticates the requesting user and confirms that the user is authorized for access to the requested service. If the authenticated user meets all prescribed conditions, the KDC issues a ticket permitting access based on a server key. The client receives the ticket and submits it to the appropriate server. The server can verify the submitted ticket and grant access to the user submitting it. The key tab file should be readable only by root, and should exist only on the machine's local disk. It should not be part of any backup, unless access to the backup data is secured as tightly as access to the machine's root password itself.
Principal	Identifies the HTTP host for the principal in the Kerberos database, which enables generation of a keytab for a host.
KRB Config File	Identifies the path to the configuration file that controls certain aspects of the Kerberos installation. A krb5.conf file must exist in the /etc directory on each UNIX node that is running Kerberos. krb5.conf contains configuration information required by the Kerberos V5 library (the default Kerberos realm and the location of the Kerberos key distribution centers for known realms).

22.6.1.2 Native LDAP Authentication Modules

Oracle provides two LDAP authentication modules: LDAP and LDAPNoPasswordAuthModule.

Both modules have the same requirements (Name and User Identity Store), as illustrated in Figure 22-6. Additional details follow the figure.

Figure 22-6 Native LDAP Authentication Module

Description of "Figure 22-6 Native LDAP Authentication Module"

Table 22-8 describes the elements in an LDAP authentication module. The same elements and values are also used in LDAPNoPasswordAuthnModule.

Note:

These standard LDAP Authentication Modules are targeted for deprecation. Future enhancements will not be available in standard modules. Oracle strongly recommends using plug-in based modules.

Table 22-8 Native LDAP Authentication Modules Definition

Element Description

Element	Description
Name	A unique name for this module.
User Identity Store	The designated LDAP user identity store must contain any user credentials required for authentication by this module. The LDAP store must be registered with Access Manager. See Also: "Registering and Managing User Identity Stores". Multiple identity store vendors are supported. Upon installation, there is only one User Identity Store, which is also the designated System Store. If you add more identity stores and designate a different store as the System Store, be sure to change the LDAP module to point to the System Store. The authentication scheme `OAMAdminConsoleScheme` relies on the LDAP module for Administrator Roles and credentials. See Also: "About using the System Store for User Identities" and "Administrator Lockout".

Name

A unique name for this module.

User Identity Store

The designated LDAP user identity store must contain any user credentials required for authentication by this module. The LDAP store must be registered with Access Manager.

Multiple identity store vendors are supported. Upon installation, there is only one User Identity Store, which is also the designated System Store. If you add more identity stores and designate a different store as the System Store, be sure to change the LDAP module to point to the System Store. The authentication scheme OAMAdminConsoleScheme relies on the LDAP module for Administrator Roles and credentials.

22.6.1.3 Native X.509 Authentication Module

Access Manager provides a pre-configured X.509 authentication module as a default. Administrators can also create new X.509 authentication modules. In cryptographic terms, X.509 is a standard for digital public key certificates used for single sign-on (SSO). X.509 specifies standard formats for public key certificates, certificate revocation lists, and attribute certificates among other things.

With X.509 digital certificates you can assume a strict hierarchical system of certificate authorities (CAs) issuing the certificates. In the X.509 system, a CA issues a certificate that binds a public key to a particular Distinguished Name, or to an Alternative Name such as an e-mail address or a DNS-entry.

The trusted root certificates of an enterprise can be distributed to all employees so that they can use the company PKI system. Certain Web browsers provide pre-installed root certificates to ensure that SSL certificates work immediately.

Access Manager uses the Online Certificate Status Protocol (OCSP) Internet protocol to maintain the security of a server and other network resources. OCSP is used for obtaining the revocation status of an X.509 digital certificate. OCSP specifies the communication syntax used between the server containing the certificate status and the client application that is informed of that status.

When a user attempts to access a server, OCSP sends a request for certificate status information. OCSP discloses to the requester that a particular network host used a particular certificate at a particular time. The server returns a response of "current", "expired," or "unknown." OCSP allows users with expired certificates a configurable grace period, during which they can access servers for the specified period before renewing.

OCSP messages are encoded in ASN.1 and are usually transmitted over HTTP. The request and response characteristic of OCSP has led to the term "OCSP responders" when referring to OCSP servers. With Access Manager, the computer hosting the Oracle Access Management Console is the OCSP responder.

An OCSP responder can return a signed response signifying that the certificate specified in the request is 'good', 'revoked' or 'unknown'. If OCSP cannot process the request, it can return an error code.

Figure 22-7 Native X.509 Authentication Module

Description of "Figure 22-7 Native X.509 Authentication Module"

Table 22-9 describes the requirements of the native X.509 authentication module.

Note:

This standard Authentication Module is targeted for deprecation. Future enhancements will not be available in standard modules. Oracle strongly recommends using plug-in based modules.

Table 22-9 X509 Authentication Module Definition

Element	Description
Name	Identifies this module definition with a unique name.
Match LDAP Attribute	Defines the LDAP distinguished name attribute to be searched against given the X509 Cert Attribute value. For example, if the certificate subject EMAIL is me@example.com and it must be matched against the "mail" LDAP Attribute, an LDAP query must search LDAP against the "mail" attribute with a value "me@example.com (cn). Default: cn
X509 Cert Attribute	Defines the certificate attribute to be used to bind the public key (attributes within subject, issuer scope to be extracted from the certificate: subject.DN, issuer.DN, subject.EMAIL, for example). See Also. Match LDAP Attribute earlier in this table.
Cert Validation Enabled	Enables (or disables if not checked) X.509 Certificate validation. When enabled, the OAM Server performs the certificate validation (rather than having the WebLogic server intercept and validate the certificate before passing it to the OAM Server). Access Manager performs the entire certificate path validation.
OCSP Enabled	Enables (or disables when not checked) the Online Certificate Status Protocol. Values are either `true` or `false`. For example: OCSP Enabled: true Note: OCSP Server Alias, OCSP Responder URL and OCSP Responder Timeout are required only when OCSP Enabled is selected.
OCSP Server Alias	An aliased name for the OSCSP Responder pointing to CA certificates in .oamkeystore file--a mapping between the aliased name and the actual instance name or the IP address of the OSCSP Responder instance.
OCSP Responder URL	Provides the URL of the Online Certificate Status Protocol responder. For example, OpenSSL Responder URL: http://localhost:6060
OCSP Responder Timeout	Specifies the grace period for users with expired certificates, which enables them to access OAM Servers for a limited time before renewing the certificate.

22.6.2 Viewing or Editing Native Authentication Modules

Users with valid Administrator credentials can modify an existing authentication module.

This includes changing the name of an existing module as well as changing other attributes.

Prerequisites

Modify each authentication scheme that references the module you will change, to use another authentication module if needed.

Note:

By default, the LDAP module is used in the authentication scheme that protects the Oracle Access Management Console. To ensure Administrator access, the LDAP module must point to the User Identity Store that is designated as the System Store. If you change the designated System Store, be sure to change the LDAP Module to reference the newly designated System Store.

In the Oracle Access Management Console, click Application Security at the top of the window.
In the Application Security console, click Authentication Modules in the Plug-ins section.
In the Search Results list, select the desired module to open its properties page.
On the properties page, modify information as needed:
- Kerberos Module: See Table 22-7
- LDAP Module: See Table 22-8
- X.509 Module: See Table 22-9 and Table 22-15
Click Apply to submit the changes and close the Confirmation window (or close the page without applying changes).
Add the updated authentication module to authentication schemes (or change to another authentication module in each authentication scheme that references this module), as described in "Managing Authentication Schemes".

22.6.3 Deleting a Native Authentication Module

Users with valid Administrator credentials can use the following procedure to delete an authentication module.

The following procedure is the same whether you are deleting a custom authentication module or a native module.

Prerequisites

In each authentication scheme that references the module to be deleted, specify another authentication module.

In the Oracle Access Management Console, click Application Security at the top of the window.
In the Application Security console, click Authentication Modules in the Plug-ins section.
Optional: Open the module to verify this is the module to remove, then close the page.
In the Search Results list, click the desired module name, then click the Delete button.
Confirm removal (or dismiss the confirmation window to retain the module).