21 Directory Proxy Server Client Authentication

This chapter describes how Directory Proxy Server identifies incoming client connections. The chapter covers the following topics:

Client Authentication Overview
Simple Bind Authentication
Certificate-Based Authentication
Anonymous Access
Directory Proxy Server Client Listeners

21.1 Client Authentication Overview

Client authentication determines how a client identifies itself to Directory Proxy Server.

From a protocol perspective, client authentication can occur at two levels:

LDAP level. Authentication occurs in the LDAP bind operation.
Connection level. Authentication occurs in the network connection established between the client and Directory Proxy Server.

Directory Proxy Server can also be configured to accept client requests without authentication.

The following list summarizes the supported authentication options. These options are discussed in more detail in the remainder of this chapter.

Simple bind authentication. Simple bind authentication occurs at the bind level. When the client binds, it provides a unique name (bind DN) and password to Directory Proxy Server. Directory Proxy Server forwards these credentials, along with the bind request, to a backend LDAP server.

Simple bind authentication can also be made over a secure connection. However, the server still identifies the client from its bind DN.
Certificate-based authentication Certificate-based authentication occurs at the connection level when the connection is secure. When authentication occurs at the connection level, the client connects over an encrypted (SSL) connection and provides a certificate. Directory Proxy Server checks the validity of the client certificate and maps the certificate to an LDAP DN.
No authentication. If the client does not provide a certificate, or a bind DN and password, no authentication occurs. In this case, the client connects to Directory Proxy Server anonymously. This is known as anonymous access.

21.2 Simple Bind Authentication

Simple bind authentication is the most common way to authenticate LDAP clients. In a simple bind, the client either binds anonymously, that is, with an empty bind DN, or by providing a DN and a password. Directory Proxy Server binds to a data source to validate the credentials and to authenticate the client. An entry for the client must exist on the data source, otherwise the client is considered to be anonymous. When a client is authenticated, Directory Proxy Server records the identity of the client.

Directory Proxy Server is configured for simple bind authentication by default. No additional configuration is required. Because the client provides a password to Directory Proxy Server, simple bind authentication is also known as password-based authentication.

21.2.1 Password Encryption and Verification

The way in which passwords are encrypted and checked depends on the type of data view through which the client accesses the data source. For information about data views, see Chapter 17, "Directory Proxy Server Distribution" and Chapter 18, "Directory Proxy Server Virtualization".

For LDAP data views, Directory Proxy Server relies on the backend LDAP server for password encryption and verification. When a client modifies a password by using an ADD or MODIFY operation, the backend LDAP server can apply a password encryption policy when it stores the password. When the client issues a BIND request, the backend LDAP server is responsible for verifying the password.

For LDIF and JDBC data views, Directory Proxy Server is responsible for password encryption and verification. When a client modifies a password, Directory Proxy Server applies the encryption policy defined by the db-pwd-encryption property of the data view. The encryption policy can be PLAIN, SHA, SSHA or SHA512. On Solaris and UNIX, you have an additional option of using the Crypt encryption policy. The password is still stored in the data source, that is, in the LDIF file or JDBC database. By default, passwords are encrypted using SSHA.

When encrypted passwords are stored, the encrypted value is prefixed by the encryption policy. So for example, a stored, encrypted password might look like {SSHA}mcasopjebjakiue or {SHA}askjdlaijfbnja. When the client issues a BIND request, Directory Proxy Server verifies the password and expects the encryption policy tag.

21.3 Certificate-Based Authentication

Certificate-based authentication over an SSL connection is the most secure type of authentication. Therefore, when authentication occurs at the connection layer, the client does not need to provide an additional name (bind DN) and password to Directory Proxy Server during the LDAP bind.

A client can only perform certificate-based authentication over an SSL connection. The basic steps in establishing an SSL connection are as follows:

The client requests that a secure connection be established.

As part of this request, Directory Proxy Server provides a server certificate to the client. A server certificate is a single certificate associated with one instance of Directory Proxy Server. When a secure connection is used, the server certificate identifies the instance of Directory Proxy Server to the client.

The establishment of the connection includes a negotiation phase. During this phase, the client and Directory Proxy Server attempt to agree on the encryption policy that is used. The server certificate contains the list of encryption policies (ciphers) that are supported by the Directory Proxy Server.
Depending on the security configuration of the proxy server, the server might require the client to provide a certificate.
The client provides a certificate to the server, either because the client is configured to do so, or because the proxy server has requested it.
The client then sends an LDAP bind request to Directory Proxy Server to establish the client's identity on that connection.
If the request is a simple bind, Directory Proxy Server uses the bind DN and password provided by the client.
If the request is a SASL external bind, Directory Proxy Server does one of two things:
- Considers the subject of the certificate as the bind DN of the client.
- Maps the certificate by searching the backend server for an entry that matches the received certificate. If the verify-certs property is set, Directory Proxy Server verifies that the received certificate is the one stored in the entry that is found.
  
  The following configuration properties determine how Directory Proxy Server performs that search:
```
cert-data-view-routing-policy
cert-data-view-routing-custom-list
cert-search-bind-dn
cert-search-bind-pwd-file
cert-search-base-dn
cert-search-attr-mappings
```
When the proxy server has the bind DN, it can verify the validity of the client.

For more information about SSL for Directory Proxy Server, see Secure Sockets Layer for Directory Proxy Server.

For certificate-based authentication to occur, Directory Proxy Server must be configured to accept client certificates and the client must be configured to use SASL external bind.

21.3.1 Configuring Certificates in Directory Proxy Server

When you create a Directory Proxy Server instance, the certificate database is automatically populated with the CA certificates of certain trusted CAs. You can add trusted CA certificates to the certificate database if necessary, by using the Directory Service Control Center (DSCC) or by using the dpadm command. For more information, see To Install a CA-Signed Server Certificate for Directory Proxy Server in Administrator's Guide for Oracle Directory Server Enterprise Edition.

When a client provides a certificate to Directory Proxy Server, the server verifies that certificate against the list of trusted CA certificates in its certificate database. The verification is successful if the server's certificate database contains the client certificate itself, or the CA certificate with which the client certificate was generated.

The server certificate can be one of the following:

Self-signed certificate. A public and private key pair, where the public key is signed by Directory Proxy Server.
Trusted CA certificate. A single certificate that is automatically generated by the company's internal certificate server or by a known Certificate Authority (CA).

Directory Proxy Server also supports the use of a server certificate chain. A server certificate chain is a collection of certificates that are automatically generated by the company's internal certificate server or by a known CA. The certificates in a chain trace back to the original CA, providing proof of identity. This proof is required each time you obtain or install a new server certificate.

When an instance of Directory Proxy Server is created, a default self-signed certificate is created. By default, Directory Proxy Server manages the SSL certificate database password internally.

You can install any number of certificates on a server. When you configure SSL for an instance of Directory Proxy Server, you must install at least one server certificate and one trusted CA certificate.

For an explanation of how certificate-based authentication works, see Certificate-Based Authentication. For information about how to configure certificate-based authentication for Directory Proxy Server, see To Configure Certificate-based Authentication in Administrator's Guide for Oracle Directory Server Enterprise Edition.

21.3.2 Using SASL External Bind

When a client binds to Directory Proxy Server with the Simple Authentication and Security Layer (SASL) external bind, Directory Proxy Server obtains the credentials of the client from the certificate, rather than from the bind DN.

The server obtains the credentials in one of two ways:

Considers the subject of the certificate as the bind DN of the client
Maps the certificate subject to data within its own database, to deduce the bind DN

SASL external bind cannot be used if Directory Proxy Server is configured for BIND replay. In BIND replay, Directory Proxy Server authenticates the client to a backend LDAP server by using the client DN and password. In SASL external bind, no password is provided by the client. Furthermore, the password that is stored in the user entry cannot be read in clear text. For information about bind replay, see Directory Proxy Server Configured for BIND Replay.

SSL can be used to protect subsequent interactions between the client and Directory Proxy Server.

For information about how to configure authentication by SASL external bind, see To Configure Directory Proxy Server for SASL External Bind in Administrator's Guide for Oracle Directory Server Enterprise Edition.

21.4 Anonymous Access

Anonymous access makes data available to any client, regardless of whether the user has authenticated.

For information about how to configure Directory Proxy Server for anonymous connections from clients, see To Configure Anonymous Access in Administrator's Guide for Oracle Directory Server Enterprise Edition.

21.5 Directory Proxy Server Client Listeners

Directory Proxy Server enables you to configure certain aspects of a client connection through a client listener. Two client listeners are provided, a secure listener (ldaps-listener) and a non-secure listener (ldap-listener).

The secure listener specifies that the connection is made to a secure port, over SSL. The non-secure listener specifies that the connection is made to a non-secure port, without SSL. Clients use either the secure listener or the non-secure listener, depending on the type of connection required by that client.

Note:

A client can also establish a secure connection to a non-secure port if the client supports Start TLS.

Both the secure and non-secure listener specify the following aspects of a client connection:

is-enabled: Specifies whether clients are able to use that listener to connect to Directory Proxy Server
listen-port: The port number on which Directory Proxy Server listens for client connections
listen-address: The IP address of the listener
connection-idle-timeout: The maximum time a client connection can remain idle before being closed
connection-read-data-timeout: The maximum time that a listener can wait for new data to be available
connection-write-data-timeout: The maximum time that a listener can wait to send results back to clients
max-connection-queue-size: The maximum size of a listener's connection queue
max-ldap-message-size: The maximum size of an LDAP message.
number-of-threads: The number of threads allocated to a listener to for simultaneous client connections and requests
use-tcp-no-delay: Whether or not TCP_NODELAY is enabled for connections between a client and Directory Proxy Server

For information about how to configure listeners, see Configuring Listeners Between Clients and Directory Proxy Server in Administrator's Guide for Oracle Directory Server Enterprise Edition.