What Else Can JNDI Do?

JNDI is a large subject, and some of the previous discussion has been quite brief (there is a lot more to attributes, searching, and references than has been shown). Today, the additional features, such as naming events and security, have been presented in a very superficial manner.

JNDI Events

JNDI supports an event model similar to the event listeners in the Java AWT and Swing classes. However, the underlying JNDI Service Provider must also provide support for the event model for a client to register event handlers.

The javax.naming.event package supports two types of JNDI event listener (both are sub-classes of NamingListener):

• NamespaceChangeListener reports on changes to the namespace objects that are added, removed, or renamed.

• ObjectChangeListener reports on changes to an object when its binding is replaced or attributes are added, removed, or replaced.

Both interfaces define appropriate methods that are called when changes occur in the JNDI namespace. A javax.naming.event.NamingEvent object is passed to the listener method to define:

• The type of event (for example, name added or object changed)

• The name binding before the event occurred

• The name binding after the event occurred

You use the EventContext.addNamingListener() method to register a NamingListener object against a context. Adding and removing a listener requires the context to implement the EventContext (or EventDirContext for Directory Services). The code to look up and register a NamingListener is similar to that shown in Listing 3.22 (please use the API documentation for further details):

Listing 3.22. Sample Code to Add a NamingListener

1: Context ic = new InitialContext();
2: EventContext ctx = (EventContext) ic.lookup("sams");
3:
4: NamingListener listener = new MyNamingListener();
5:
6: ctx.addNamingListener("book", EventContext.ONELEVEL_SCOPE, listener);
						

Listing 3.22 registers a listener against the sams context and listens for events on the book name. Depending on the underlying Service Provider, the book name need not exist when you register the listener.

You can register a NamingListener to listen for several objects either by listening on a context (rather than an object) or by using attribute filters to specify the required objects.

JNDI event handling provides an effective means for monitoring changes to a namespace to maintain up-to-date information about the registered objects.

Security

JNDI security depends on the underlying Service Provider. Simple services, such as RMI and the CORBA name service (both of which the J2EE RI implementation supplies), 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. Most live J2EE implementations will make use of 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.

You can use a JNDI properties file to supply client authentication information, but more usually you code the information within the client program. Usually, your application must obtain the client authentication dynamically.

If you use strong (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, which has no known decryption technique.

Day 15, “Security,” discuses the whole topic of J2EE and JNDI security.