Security and JNDI

Although JNDI is part of J2SE rather than J2EE, name servers are most commonly used with enterprise applications, many of which use J2EE. The underlying Service Provider implements the security for the naming and directory service. In most circumstances, a secure directory service will use LDAP or a service that has an LDAP interface (Active Directory or NDS), and so this section will describe LDAP security requirements.

You may want to check back to Day 3, “Naming and Directory Services,” to remind yourself about JNDI before reading the rest of this section.

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 a client does not supply any security information, it is treated as an anonymous client.

Security credentials to JNDI are provided as properties. These can be defined in a jndi.properties file or supplied as a HashTable to the InitialContext constructor.

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 a space-separated list of authentication schemes 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 the encrypted data (such as a digital certificate) the authentication mechanism needs in order to authenticate the client.

If values for these properties are defined in code using a HashTable, the string constants defined in the javax.naming.Context class should be used instead. These constants are as follows:

• Context.SECURITY_AUTHENTICATION

• Context.SECURITY_PRINCIPAL

• Context.SECURITY_CREDENTIALS

Simple LDAP Authentication

Simple LDAP authentication is easy to use but passes security information, such as the principal name and password, in plain text across the network. Simple authentication is vulnerable to hackers monitoring network traffic to collect usernames and passwords.

To use simple LDAP authentication, the following properties are needed:

• The authentication is set to simple.

• The security principal is the fully-qualified Distinguished Name (DN) of the LDAP user.

• The security credentials are set to the user's plain text password.

The following example shows how to define simple authentication for a fictitious user called Winston with a password of cigar:

env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "cn=Winston,ou=Customers,o=Agency,c=us");
env.put(Context.SECURITY_CREDENTIALS, "cigar");

// Create the initial context
DirContext ctx = new InitialDirContext(env);

SASL Authentication

If you use SASL authentication, the java.naming.security.authentication value consists 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. This is proposed by RFC2829 to be a mandatory default for LDAP v3 servers.

Additional schemes may also be supported.

An LDAP server stores a list of SASL mechanisms against the attribute supportedSASLMechanisms for the root context. Listing 15.5 shows a program that lists out the SASL mechanisms for an LDAP server.

Listing 15.5. Full Text of ListSASL.java

import javax.naming.*;
import javax.naming.directory.*;

public class ListSASL {
    public static void main (String[] args) {
        try {
            // Create initial context
            DirContext ctx = new InitialDirContext();

            // get supported SASL Mechanisms
            Attributes attrs = ctx.getAttributes("supportedSASLMechanisms");
            NamingEnumeration ae = attrs.getAll();
            while (ae.hasMore()) {
                Attribute attr = (Attribute)ae.next();
                System.out.println("  attribute: " + attr.getID());
                NamingEnumeration e = attr.getAll();
                while (e.hasMore())
                    System.out.println("    value: " + e.next());
            }
        }
        catch (NamingException ex) {
            System.out.println ("Naming error: "+ex);
            ex.printStackTrace();
            System.exit(1);
        }
    }
}

Remember that the default JNDI server for the J2EE RI is a CORBA name server and does not support a directory naming service so you cannot test this program using the J2EE RI.

The following code fragment shows how the sample user (Winston) can define the security credential properties to use Digest MD5:

env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL, "cn=Winston,ou=Customers,o=Agency,c=us ");
env.put(Context.SECURITY_CREDENTIALS, "cigar");

// Create the initial context
DirContext ctx = new InitialDirContext(env);

To use Digest MD5, the Java Cryptography Extension (JCE) must be installed on your system. JCE is included in JDK 1.4 but must be downloaded from Sun Microsystems' Web site and installed for earlier versions of the JDK.

The subject of JCE and LDAP SASL authentication is a whole day's lesson in its own right, and there isn't time today to do any more work in this area. If you are interested in finding out more about JCE and JNDI security, the JNDI Tutorial on Sun Microsystems' Web site is an excellent starting point.