Previous | Next | Trail Map | Beyond the Basics | Miscellaneous


The JNDI does not define a security model. Rather, it uses the security models that are in place in the underlying Java platform and in the underlying naming/directory service. However, in terms of security support, the JNDI does provide security-related environment properties that allow the JNDI client to specify commonly needed security-related information. These properties are listed in the Environment Properties (in the Beyond the Basics trail) lesson. Following is a brief summary of them. Service providers are encouraged to use these properties when they apply to accessing the underlying naming/directory service. However, providers may use other means to authenticate their clients, such as the Java Authentication and Authorization Service.

Environment Properties

You need to keep in mind that the environment properties contain possibly security-sensitive information (such as passwords). You also need to understand that when you supply environment properties to a service provider (by using the InitialContext constructors(in the API reference documentation)), they are passed by the provider to factories (see the Object Factories (in the Java Objects and the Directory trail), State Factories (in the Java Objects and the Directory trail), and Response Control Factories (in the Tips for LDAP Users trail) lessons for details). You should ensure that all factories and providers that you use can be trusted with possibly security-sensitive information.

Application resource files, as described in the Environment Properties (in the Beyond the Basics trail), allow you to easily specify environment properties. The JNDI will read and use all application resource files in the classpath. Because environment properties can affect the factories that you use (see the next section), you should be careful about the class definitions and application resource files that you include in your classpath.


The JNDI architecture is designed to be very flexible. You can dynamically choose service providers, as well as customize them by using object factories, state factories, and response control factories. Thus, depending on the configuration of providers and factories, a program's behavior can vary dramatically.

This flexibility, though powerful, has security implications. You should ensure that the factories used are trusted. Malicious factories can return wrong or intentionally misleading data or corrupt your underlying naming/directory service. Because naming/directory services are often used to store security-related information, you should take extra precaution to include only valid and trusted factories.

Instances of Context

An instance of Context(in the API reference documentation) or one of its subinterfaces is a possibly authenticated connection to the underlying naming/directory service. It can be returned by various methods in the JNDI API and SPI, including the following:
Context.lookup()(in the API reference documentation) Context.lookupLink()(in the API reference documentation)
Context.listBindings()(in the API reference documentation) Context.createSubcontext()(in the API reference documentation)
DirContext.createSubcontext()(in the API reference documentation) various forms of the API reference documentation)
DirContext.getSchema()(in the API reference documentation) DirContext.getSchemaClassDefinition()(in the API reference documentation)
Attribute.getAttributeDefinition()(in the API reference documentation) Attribute.getAttributeSyntaxDefinition()(in the API reference documentation)
LdapContext.newInstance(in the API reference documentation) NamingManager.getContinuationContext()(in the API reference documentation)
DirectoryManager.getContinuationDirContext()(in the API reference documentation) NamingManager.getObjectInstance() (in the API reference documentation)
DirectoryManager.getObjectInstance() (in the API reference documentation) NamingManager.getURLContext() (in the API reference documentation)
NamingManager.getInitialContext() (in the API reference documentation) NamingEvent.getEventContext (in the API reference documentation) and getSource() (inherited from java.util.EventObject).
NamingExceptionEvent.getEventContext (in the API reference documentation) and getSource() (inherited from java.util.EventObject). UnsolicitedNotificationEvent.getSource() (inherited from java.util.EventObject).

Context instances are also passed to object, state, and control factories.

As with environment properties, you should not pass Context instances to untrusted service providers, factories, or any other untrusted code.

Previous | Next | Trail Map | Beyond the Basics | Miscellaneous