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 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.
- Context.SECURITY_AUTHENTICATION ("java.naming.security.authentication").
Specifies the authentication mechanism to use.- Context.SECURITY_PRINCIPAL ("java.naming.security.principal").
Specifies the name of the user/program that is doing the authentication. Depends on the value of the Context.SECURITY_AUTHENTICATION property.- Context.SECURITY_CREDENTIALS ("java.naming.security.credentials").
Specifies the credentials of the user/program doing the authentication. Depends on the value of the Context.SECURITY_AUTHENTICATION property.- Context.SECURITY_PROTOCOL ("java.naming.security.protocol").
Specifies the security protocol to use.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), they are passed by the provider to factories (see the Object Factories , State Factories , and Response Control Factories 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 , 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.
Factories
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 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() Context.lookupLink() Context.listBindings() Context.createSubcontext() DirContext.createSubcontext() various forms of DirContext.search() DirContext.getSchema() DirContext.getSchemaClassDefinition() Attribute.getAttributeDefinition() Attribute.getAttributeSyntaxDefinition() LdapContext.newInstance NamingManager.getContinuationContext() DirectoryManager.getContinuationDirContext() NamingManager.getObjectInstance() DirectoryManager.getObjectInstance() NamingManager.getURLContext() NamingManager.getInitialContext() NamingEvent.getEventContext and getSource() (inherited from java.util.EventObject). NamingExceptionEvent.getEventContext 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.
Miscellaneous |