JNDI Security

JNDI security depends on the underlying Service Provider. Simple services, such as the transient CORBA name service supplied with J2SE, do not support security. These services allow any client to perform any operation.

In a production environment, security is paramount to ensuring the integrity of the data in the JNDI server. Many organizations will use LDAP to provide a naming service that supports security.

LDAP security is based on three categories:

• Anonymous— No security information is provided.

• Simple— The client provides a clear text name and password.

• Simple Authentication and Security Layer (SASL)— The client and server negotiate an authentication system based on a challenge and response protocol that conforms to RFC2222.

If the client does not supply any security information (as in all the examples shown today), the client is treated as an anonymous client.

The following JNDI properties provide security information:

• java.naming.security.authentication is set to a String to define the authentication mechanism used (one of none, simple, or the name of an SASL authentication system supported by the LDAP server).

• java.naming.security.principal is set to the fully qualified domain name of the client to authenticate.

• java.naming.security.credentials is a password or encrypted data (such as a digital certificate) that the implementation uses to authenticate the client.

If you do not define any of these properties, the implementation uses anonymous (java.naming.security.authentication=none) authentication.

It is possible to use a JNDI properties file to supply client authentication information, but more usually you code this information within the client program. Typically, your application will obtain the client authentication dynamically.

If you use SASL (not simple or anonymous) authentication, the java.naming.security.authentication value can consist of a space-separated list of authentication mechanisms. Depending on the LDAP service provider, JNDI can support the following authentication schemes:

• External— Allows JNDI to use any authentication system. The client must define a callback mechanism for JNDI to hook into the client's authentication mechanism.

• GSSAPI (Kerberos v5)— A well-known, token-based security mechanism.

• Digest MD5— Uses the Java Cryptography Extension (JCE) to support client authentication using the MD5 encryption algorithm.

The Day 15, “Security,” chapter discuses the topic of J2EE and JNDI security in more detail.