33 Managing Authentication

This chapter gives a conceptual overview of Oracle Internet Directory authentication features. It contains these topics:

33.1 Introduction to Authentication

Authentication is the process by which the directory server establishes the true identity of the user connecting to the directory. It occurs when an LDAP session is established with the bind operation. Thus every session has an associated user identity.

To verify the identities of users, hosts, and clients, Oracle Internet Directory enables three general kinds of authentication, and these are described in these topics:

33.1.1 Direct Authentication

This section describes the three kinds of direct authentication available within Oracle Internet Directory, and about how SASL-enabled clients authenticate to a directory server. The three kinds of direct authentication options are:

  • Anonymous authentication

    When users authenticate anonymously, they simply leave the user name and password fields blank when they log in. Each anonymous user then exercises whatever privileges are specified for anonymous users.

  • Simple authentication

    When using simple authentication, the client identifies itself to the server with a DN and a password that are not encrypted when sent over the network.

  • Authentication by using Simple Authentication and Security Layer (SASL)

    This is a method for adding authentication support to connection-based protocols. To use SASL, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If the use of SASL is successfully negotiated, then a security layer is inserted between the protocol and the connection.

    Oracle Internet Directory supports two authentication mechanisms with SASL:

    • Digest MD5: The required authentication mechanism within LDAP Version 3 (RFC 2829). It uses the MD5 hash function to convert a message of any length to a 128 bit message digest that can be used as a verifier for client/server authentication.

    • External authentication: Mechanism using SSL mutual authentication. In this case, the client, in lieu of a user name and password, authenticates to the server with a certificate, token, or some other device. Certificate authentication can take the following forms:

      • Exact match: the subject DN in the client certificate is compared with the user DN in the directory. If the two values match, a bind occurs.

      • Certificate hash: The client certificate is hashed and is then compared with the hashed value of the certificate stored in the directory. If the two values match and only one DN is associated with the pair, a bind occurs. If two or more DNs are associated, an error is returned because certificate hash and user DN is an n-to-1 mapping and not a 1-to-n mapping. That is, you can have many certificates associated with one DN, but only one DN associated with a certificate.

      • Exact match/certificate hash: An exact-match search is performed first. If this search yields nothing, a certificate hash is performed.

      To choose one of these methods, edit the DSA configuration attribute orclpkimatchingrule as prescribed in "Oracle Identity Management LDAP Attribute Reference" in Oracle Fusion Middleware Reference for Oracle Identity Management. (For authentication, an orclpkimatchingrule value of 3 or 4 is equivalent to a value of 2.)

Notes:

See Also:

  • Section 33.1.4, "Simple Authentication and Security Layer (SASL)"

  • The Web site of the Internet Engineering Task Force (IETF) at http://www.ietf.org for the following RFCs: RFC 2829, which specifies SASL Digest-MD5 as the required authentication mechanism for LDAP Version 3 servers; RFC 2831, which describes the Digest-MD5 mechanism; RFC 2617, which describes the HTTP Digest authentication mechanism on which SASL Digest-MD5 is based

33.1.2 Indirect Authentication

Indirect authentication occurs through any entity that has credentials in the directory—for example, an application such as the Oracle Internet Directory Self-Service Console, or a middle tier such as a firewall or a RADIUS server. The application or middle tier becomes a proxy user. A proxy user has the privilege to impersonate an end user, performing on that user's behalf those operations for which that user has privileges.

Figure 33-1 and the accompanying text explain how indirect authentication takes place.

Figure 33-1 Indirect Authentication

This illustration is described in the text.

Indirect authentication takes place as follows:

  1. The end user sends to the application or middle tier a request containing a query to Oracle Internet Directory. The application or middle tier authenticates the end user.

  2. The application or middle tier binds to the directory.

  3. The application or middle tier performs a second bind, this time using the DN of the end user. It does not enter the end user's password.

  4. The directory server recognizes this second bind as an attempt by the application or middle tier to switch to the end user's identity. It trusts the authentication granted to the end user by the application or middle tier, but must verify that the application or middle tier has the right to be the proxy for this user. It checks to see whether the ACP governing the end user entry gives this application or middle tier the proxy right for this end user.

    • If the end user entry does give the application or middle tier the necessary proxy right, then the directory server changes the authorization identity to that of the end user. All subsequent operations occur as if that end user had connected directly to the server and had been directly authenticated.

    • If the end user entry does not give the application or middle tier the necessary proxy right, then the directory server returns an "Insufficient Access" error message.

The directory server can, in the same session, authenticate and authorize other end users. It can also switch the session from the end user to the application or middle tier that opened the session.

To close the session, the application or middle tier sends an unbind request to the directory server.

For example, suppose you have:

  • A middle tier that binds to the directory as cn=User1, which has proxy access on the entire directory

  • An end user that can bind to the directory as cn=User2

When this end user sends to the application or middle tier a request containing a query to the directory, the application or middle tier authenticates the end user. The middle tier service then binds to the directory by using its own identity, cn=User1, then performs a second bind, this time by using only the DN of the end user, cn=User2. The Oracle directory server recognizes this second bind as an attempt by the proxy user to impersonate the end user. After the directory server verifies that cn=user1 has proxy access, it allows this second bind to succeed. It does not require any further validation of the end-user DN, such as a password. For the rest of the session, all LDAP operations are access-controlled as if cn=User2 were performing them.

If one user is being serviced by an application, and another user subsequently requests a service of that same application, then the application can establish a new connection and proceed as previously described without disrupting that prior session. If, however, no prior user is still being serviced, then the existing established connection can be re-used again and again without the need for a new connection.

33.1.3 External Authentication

Perhaps your enterprise stores user security credentials in a repository other than Oracle Internet Directory—for example, a database or another LDAP directory. With Oracle Internet Directory external authentication and password modification plug-ins, you can use these credentials for user authentication to Oracle components. You do not need to store the credentials in Oracle Internet Directory and then worry about keeping them synchronized.

33.1.4 Simple Authentication and Security Layer (SASL)

The section "Direct Authentication" introduced the use of SASL within an Oracle Internet Directory environment. This section describes more fully how SASL works. It contains these topics:

How a SASL-Enabled Client Authenticates to a Directory Server by Using Digest-MD5

Note:

To use SASL Digest-MD5 with realms, SASL must generate a Dynamic User Verifier. You must enable reversible password generation. For more information, see "SASL Authentication by Using Digest-MD5" in the Oracle Fusion Middleware Application Developer's Guide for Oracle Identity Management.

When a SASL-enabled client seeks Digest-MD5 authentication to a server, the authentication process is as follows:

  1. The directory server sends to the LDAP client a digest-challenge that includes various Digest-MD5 authentication options that it supports and a special token.

  2. The client selects an authentication option, then sends a digest-response to the server indicating the option it has selected. The response includes some secure tokens and a client credential in encrypted format. This allows it to authenticate itself to the server.

  3. The directory server then decrypts and verifies the client credential from the response.

How a SASL-Enabled Client Authenticates to a Directory Server by Using External Authentication

Oracle Internet Directory provides SASL-external authentication over an SSL connection in which both client and server authenticate themselves to each other by providing certificates. The DN is derived from the client certificate used in the SSL network negotiation.

When a client seeks authentication to a directory server by using an external authentication mechanism such as SSL, the authentication process is as follows:

  1. The client sends an initial message with the authorization identity.

  2. The directory server uses information external to SASL to determine whether the client can validly authenticate as the authorization identity. If the client can validly authenticate, then the directory server indicates successful completion of the authentication exchange. Otherwise, the directory server indicates failure.

The system providing the external information may be IPsec or SSL/TLS. The authorization identity is derived as follows:

  • In case of exact match, the authorization identity is derived from the client authentication credentials in the system providing external authentication—for example, the client SSL certificate.

  • If the client sends an empty string as the authorization identity, then the authorization identity is derived from the client authentication credentials in the system providing external authentication—for example, the SSL certificate.

33.2 Configuring Certificate Authentication Method by Using Fusion Middleware Control

To configure the value of the DSA configuration attribute orclPKIMatchingRule, which determines the method used for certificate authentication, use the Oracle Internet Directory Shared Properties page of Oracle Enterprise Manager Fusion Middleware Control. Select Administration, then Shared Properties from the Oracle Internet Directory menu. Select the desired matching method from the list for PKI Matching Rule.

33.3 Configuring SASL Authentication by Using Fusion Middleware Control

To configure SASL Authentication by using Oracle Enterprise Manager Fusion Middleware Control:

  1. Select Administration, then Server Properties from the Oracle Internet Directory menu, then select SASL.

  2. Select the desired types for MD5 SASL Authentication Mode.

  3. If you select Authentication with Integrity and Privacy Protection, you are presented with choices for SASL Cipher Choice for Privacy Protection. Select the desired types. Choices are: rc4-56, des, 3des, rc4, and rc4-40. All five are enabled by default. At least des and 3des must be configured, or SASL authentication fails.

  4. If desired, select Enable SASL Authentication. Before enabling SASL Authentication, ensure that Oracle Internet Directory is configured to perform mutual authentication. See Section 27.2, "Configuring SSL by Using Fusion Middleware Control."

  5. Choose Apply.

    Restart the server after changing any of the attributes on the SASL tab.

    Table 33-1 Configuration Attributes on Server Properties, SASL Tab

    Field or Heading Configuration Attribute

    MD5 SASL Authentication Mode

    orclsaslauthenticationmode

    SASL Cipher Choice for Privacy Protection

    orclsaslcipherchoice

    External SASL Authentication Mode

    orclsaslmechanism


33.4 Configuring Certificate Authentication Method by Using Command-Line Tools

To configure the value of the DSA configuration attribute orclPKIMatchingRule, which determines the method used for certificate authentication, use ldapmodify, with a command line similar to this

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile 

and with an LDIF file similar to this:

dn: cn=dsaconfig, cn=configsets, cn=oracle internet directory
changetype: modify
replace: orclPKIMatchingRule
orclPKIMatchingRule: 1

The values are:

  • 0 - Exact match. The PKI certificate DN must match the user entry DN.

  • 1 - Certificate search. Check to see if the user has a PKI certificate provisioned into Oracle Internet Directory.

  • 2 - A combination of exact match and certificate search. If the exact match fails, then a certificate search is performed.

  • 3 - Mapping rule only. Use a mapping rule to map user PKI certificate DNs to Oracle Internet Directory DNs.

  • 4 - Try in order: 1 (mapping rule), 2 (certificate search), 3 (exact match).

33.5 Configuring SASL Authentication by Using the Command Line

Table 33-2 lists the SASL authentication attributes. They reside in the instance-specific configuration entry.

Table 33-2 SASL Authentication Attributes

Attribute Description Default Possible Values

orclsaslauthenticationmode

SASL Authentication Mode

1

auth, auth-int, auth-conf.

orclsaslcipherchoice

SASL Cipher Choice

Rc4-56,rc4-40,rc4,des,3des

Any combination of Rc4-56, des, 3des, rc4, rc4-40

orclsaslmechanism

SASL Mechanism

DIGEST-MD5, EXTERNAL

DIGEST-MD5, EXTERNAL


MD5 SASL Authentication Mode is controlled by the attribute orclsaslauthenticationmode. Table 33-3 lists the possible modes. You can specify all three values or any subset as a comma separated string.

Table 33-3 SASL Authentication Modes

orclsaslauthenticationmode Value Mode Description

1

auth

Authentication only.

2

auth-int

Authentication with integrity protection. A checksum is performed on the channel.

3

auth-conf

Authentication with integrity protection and encryption. The channel is encrypted.


If you set orclsaslauthenticationmode to 3 (auth-conf), you must also choose values for orclsaslcipherchoice. Choices are: rc4-56, des, 3des, rc4, and rc4-40. All five are enabled by default. At least des and 3des must be configured, or SASL authentication fails.

The variable orclsaslmechanism controls which authentication mechanisms are supported with SASL. The values DIGEST-MD5 and EXTERNAL are set by default. Do not disable Digest-MD5 authentication. It is the required authentication mechanism for LDAP Version 3 servers. You can disable external authentication by using ldapmodify. Disable external authentication if you do not configure Oracle Internet Directory to perform SSL client and server authentication.

Restart the server after changing any of the SASL attributes.

33.6 Introduction to Anonymous Binds

An anonymous bind is one that uses simple authentication with no password. By default, the directory server allows anonymous bind, but allows only search operations on root DSE entry for anonymous users. You can configure the server to allow all anonymous binds or to disallow anonymous binds. This behavior is controlled by the orclanonymousbindsflag attribute of the s server instance-specific configuration entry. Table 33-4 lists the allowed values for orclanonymousbindsflag and the resulting directory server behavior.

Table 33-4 Orclanonymousbindsflag Value and Directory Server Behavior

orclAnonymousBindsFlag Value Directory Server Behavior

0

Disallows anonymous bind

1

Allows anonymous bind

2

Allows anonymous bind but allows only search operations on root DSE entry for anonymous users (default)


33.7 Managing Anonymous Binds

In Oracle Internet Directory 11g Release 1 (11.1.1), anonymous binds are allowed by default, but anonymous users can only perform search operations on the root DSE entry. You can use either Fusion Middleware Control or the command line to change the server's behavior with respect to anonymous binds.

33.7.1 Managing Anonymous Binds by Using Fusion Middleware Control

To manage anonymous binds by using Oracle Enterprise Manager Fusion Middleware Control:

  1. Select Administration, then Server Properties from the Oracle Internet Directory menu, then select the General. tab.

  2. From the Anonymous Binds list, select Allows to enable anonymous binds. Select Disallow except for Read Access on the root DSE to allow only search operations on root DSE entry for anonymous users.

To disable anonymous binds by using:

  1. Select Administration, then Server Properties from the Oracle Internet Directory menu, then select the General. tab.

  2. From the Anonymous Binds list, select Disallow.

33.7.2 Managing Anonymous Binds by Using the Command Line

To enable all anonymous bind on the Oracle Internet Directory instance with componentName oid1 using ldapmodify, you would type:

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile 

with an LDIF file such as:

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclAnonymousBindsFlag
orclAnonymousBindsFlag: 1

To disable all anonymous binds, you would use a similar LDIF file with the last line changed to:

orclAnonymousBindsFlag: 0