A directory service adds attributes and extends a naming service. A naming service is a set of contexts of the same type, that is, the contexts have the same naming convention. A context is a set of name and object bindings and may have subcontexts, where each object may be related to another object between the same context. In a system, each object is associated with a name. This association is called a binding . Each object can be found by that name via the naming service.
For instance, the Internet Domain Name Service (DNS) maps machine names to IP addresses, such as www.sun.com to 192.9.48.5, and each system has a naming convention . An example of a naming convention is the UNIX file system where a file is relative to the root of the file system and uses a forward slash (/), as in /usr/bin/readmefirst where readmefirst is a file in the bin subdirectory of the usr directory located at the root . In this example, the file system is a context, and the subdirectory is a subcontext.
A directory service provides operations to manage (create, delete, modify, and so on) the attributes associated with the objects within it. You can find the JNDI API at the SUN Web site ( http://java.sun.com/j2se/1.4/docs/guide/jndi/spec/jndi/ ).
JNDI architecture overview
The Java Naming and Directory Interface (JNDI) is the API that supports the naming and directory functionality to Java applications. The JNDI architecture also provides a Service Provider Interface (SPI) to allow different naming and directory services providers to be seamlessly plugged in without affecting the application (which is using the JNDI API). Figure 27-2 illustrates how an application using the JNDI API can use different providers (such as LDAP and CORBA) by the JNDI SPI layer support.
Figure 27-2: The JNDI architecture The JNDI API provides methods to perform standard directory operations such as associating attributes to named Java objects and searching for those objects based on their attributes.
The packages that form the JNDI API are as follows :
-
javax.naming, which provides the classes and interfaces to access naming services.
The Context interface is provided by this package. Context is the core interface that defines basic methods such as looking up an object, binding/unbinding objects, renaming objects, and creating and destroying subcontexts.
In JNDI, every name is relative to a context. The InitialContext provides a starting point for naming and directory operations. The following code snippet is an example of how to get the initial context and use it to find the Home interface for a Project EJB.
Context ctx = new InitialContext(); projectHome = (ProjectHome)ctx.lookup("projinfo.ProjectHome"); Context.lookup() is the most commonly used operation. You provide the name of the object, and Context.lookup() returns the object bound to that name. There are other binding operations such as Context.listBindings(), which returns an enumeration of tuples (of the object name, the object's class, and the object itself).
-
javax.naming.directory, which extends the javax.naming package to provide access to directories.
Directory objects can have zero or more attributes, and JNDI has the Attribute interface and Attributes interface (which is a collection of Attributes ). JNDI also provides implementation of these interfaces in BasicAttribute and BasicAttributes . The DirContext interface represents a directory context and provides methods for examining and updating attributes associated with the directory context. The DirContext interface also provides overloaded search methods.
| Tip | Use DirContext.modifyAttributes() to modify the directory. Modifications to Attribute and Attributes do not affect the underlying directory. |
A schema describes the rules that define the structure of the namespace and attributes. Applications can retrieve the schema associated with a directory object when the underlying context implementation provides the necessary support. Using a schema allows for a uniform way to access the directory objects. The schema can be accessed via the DirContext.getSchema and DirContext.getSchemaClassDefinition methods.
-
javax.naming.event, which provides classes and interfaces for event notification in naming and directory services.
A NamingEvent represents an event generated by a naming/directory service. The NamingEvent class defines four types of events: OBJECT_ADDED , OBJECT_REMOVED , OBJECT_RENAMED, and OBJECT_CHANGED . A NamingListener is an object that listens for NamingEvents . The NamespaceChangeListener interface listens for namespace changes, while the ObjectChangeListener listens for changes to an object's contents. For events notifications to be received, the listener must be registered with either an EventContext or an EventDirContext .
-
javax.naming.ldap, which provides classes and interfaces for using features specific to LDAP v3 not covered by the javax.naming.directory package.
This package is primarily for applications that need to use extended operations, controls, or unsolicited notifications. The LDAP v3 (RFC 2251) specifies a way to transmit "yet-to-be defined" operations (these are the extended operations ). In addition, the LDAP v3 protocol allows any request or reponse to be augmented by "yet-to-be defined" modifiers - these are referred as controls .
JNDI classifies the request controls into connection (affecting how a connection is created) and context (affecting context methods) request controls. The InitialLdapContext is the initial LDAP context to perform extended operations and controls.
-
javax.naming.spi, which is the Service Provider Interface that allows different providers to be dynamically plugged in under the JNDI API.
Understanding security with JNDI
JNDI has two main options: with and without security manager. If there is no security manager installed, the code is trusted and the application can access service providers from the local classpath. If a security manager is installed, there is trusted and untrusted code within the same application and access to service providers may be restricted.
JNDI does not define a common security interface for accessing naming and directory servers. The different service providers supply the security operations such as authentication and access control. JNDI, however, provides the means to pass the related security information to the service provider.
| Tip | Clients can pass context information of an environment to service providers. You must be careful because the context may contain sensitive information that should not be available to untrusted sources. |
Here is a list of some of the environment properties that contain security-sensitive information:
-
Context.SECURITY_AUTHENTICATION : Specifies the authentication mechanism. The following lines of code set the environment to use anonymous authentication via the context.
// get initial context DirContext ctx = new InitialDirContext(); // ... // set to anonymous authentication ctx.addToEnvironment(Context.SECURITY_AUTHENTICATION, "none");
-
Context.SECURITY_CREDENTIALS : Specifies the credentials of the authenticating entity.
-
Context.SECURITY_PRINCIPAL : Specifies the name of the authenticating entity.
-
Context.SECURITY_PROTOCOL : Specifies the security protocol to use.
The following code example tries to authenticate a user with LDAP, using simple authentication, a principal with name Bob, and a password boby .
// authenticate 'Bob' env.put(Context.SECURITY_AUTHENTICATION, "simple"); env.put(Context.SECURITY_PRINCIPAL, "cn=Bob, ou=HR, o=XYZ"); env.put(Context.SECURITY_CREDENTIALS, "boby");
If the authentication fails because the password is incorrect, a javax.naming.AuthenticationException is thrown. Different servers support different authentication mechanisms. If you request one that the server does not support, you get a javax.naming.AuthenticationNotSupportedException .
In addition, the service provider is responsible for securing security-sensitive information. For instance, instead of using the context and its properties, the service provider could use JAAS for authorization and authentication purposes. The service provider also could disallow any thread (with execution context or trust level different than the original) from reading the context handle. The service provider could not allow access to sensitive data or allow access to only trusted secure code.
