------------------------------ LDAP Service Provider for JNDI ------------------------------ This is the FCS 1.0.2 release of the JNDI/LDAP service provider. Please send feedback to jndi@java.sun.com 1.0 INTRODUCTION ---------------- The LDAP service provider implements the DirContext interface. You can use this provider with JNDI in order to access LDAP directories. The provider presents the entries and associated attributes from the LDAP directory as JNDI DirContext and Attribute objects, respectively. LDAP distinguished names are used to name DirContext objects. LDAP attribute types are used to identify Attribute objects. 2.0 CONFORMANCE --------------- The LDAP service provider for JNDI supports LDAP Version 2 (LDAPv2) and conforms to the following specifications: - Lightweight Directory Access Protocol [RFC-1777] - The String Representation of Standard Attribute Syntaxes [RFC-1778] - A String Representation of Distinguished Names [RFC-1779] - A String Representation of LDAP Search Filters [RFC-1960] - An LDAP URL Format [RFC-1959] In addition, it also supports LDAP Version 3 (LDAPv3) and conforms to the following specifications: - Lightweight Directory Access Protocol (v3) [RFC-2251] - Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions [RFC-2252] - Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names [RFC-2253] - The String Representation of LDAP Search Filters [RFC-2254] 3.0 ENVIRONMENT PROPERTIES -------------------------- The following JNDI environment properties are relevant for the LDAP service provider. In the examples given, 'env' an instance of Hashtable and is the environment properties that will be used for creating the initial context. java.naming.factory.initial This environment property is used to select the LDAP provider; it's not actually used by the provider itself. It specifies the class name of the initial context factory for the provider. For example, the following sets the initial context factory to be that of Sun's LDAP provider. env.put(Context.INITIAL_CONTEXT, "com.sun.jndi.ldap.LdapCtxFactory"); This environment property must be set if you are using LDAP for the initial context. The only exception is if you supply only URLs to the initial context, in which case, you don't need to specify this property. See the NAMES & URL Section below. java.naming.provider.url Specifies LDAP server information. For example, the following specifies to use the LDAP server running on the machine "localhost" at port 636 env.put(Context.PROVIDER_URL, "ldap://localhost:636"); If this environment property has not been set then the provider will attempt to access an LDAP server at TCP port number 389 on the local host. The only exception is if you supply URLs to the initial context, in which case, the server and port information will be extracted from the URLs. java.naming.referral Specifies how referrals shall be handled by the provider. Three possible values are defined: follow - automatically follow any referrals throw - throw a ReferralException for each referral ignore - ignore referrals if they appear in results and instruct the server to treat them like ordinary attributes if they appear in entries. For LDAP v3, a manage referral control is sent with each request. For example, the following sets the referral handling to throw a ReferralException: env.put(Context.REFERRAL, "throw"); If this environment property has not been set then the provider will ignore referrals. NOTE: the default setting (ignore) for this property causes the ManageDsaIT LDAP control (non-critical) to be sent with each LDAPv3 request. The ManageDsaIT control is defined in: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-referral-00.txt LDAP servers which do not support this control will ignore it and process the request as normal. If a referral is received by JNDI and the "ignore" setting is active then the referral is ignored and a PartialResultException is thrown to indicate an incomplete result. java.naming.batchsize Specifies that search results are to be returned in batches. A setting of zero indicates that the provider should block until all results have been received. For example, the following sets the batch size to be 24: env.put(Context.BATCHSIZE, "24"); If this environment property has not been set then search results are returned in batches of one. java.naming.security.authentication Specifies the authentication mechanism for the provider to use. Only one SASL (RFC-2222) mechanism is currently supported. The following values are permitted for this property: CRAM-MD5 - use the CRAM-MD5 (RFC-2195) SASL mechanism none - use no authentication (anonymous) simple - use weak authentication (cleartext password) For example, the following specifies to use simple authentication: env.put(Context.SECURITY_AUTHENTICATION, "simple"); If this environment property has not been set but the java.naming.security.principal environment property has been set then the provider will use the CRAM-MD5 SASL mechanism. If neither have been set then the provider will use anonymous bind. NOTE: the strong authentication setting is currently not supported. java.naming.security.principal Specifies the identity of the principal to be authenticated. Its format is a string distinguished name (RFC-2253). For example, the following specifies the principal name to be "cn=admin,o=sun,c=us": env.put(Context.SECURITY_PRINCIPAL, "cn=admin,o=sun,c=us"); If this environment property has not been set then the provider will use anonymous bind. java.naming.security.credentials Specifies the credentials of the principal to be authenticated. Its format depends on the selected authentication mechanism. For example, the following specifies the credentials to be "secret": env.put(Context.SECURITY_CREDENTIALS, "secret"); For the CRAM-MD5 and simple authentication mechanisms, you can supply either a java.lang.String or a byte[] containing the password. If it is a java.lang.String, for LDAP v3, the password is encoded into a byte array using UTF-8; for LDAP v2, the encoding used is ISO-Latin-1. If it is a byte[], the argument is used as is. java.naming.security.protocol Specifies the security protocol for the provider to use. One possible value is defined: ssl - use Secure Sockets Layer Version 3.0 For example, the following specifies that SSL should be used: env.put(Context.SECURITY_PROTOCOL, "ssl"); When this environment property has been set and the java.naming.ldap.factory.socket property has not been set, then the socket factory "javax.net.ssl.SSLSocketFactory" is used. In order to use this feature, you must have the SSL classes in your classpath or execution environment (such as HotJava or Java Web Server). See http://java.sun.com/security/ssl/API_users_guide.html for details. If java.naming.ldap.factory.socket property has been set, the socket factory specified therein is used. See the description for java.naming.ldap.factory.socket for details. NOTE: If you use SSL to connect to a server on a port that is NOT using SSL, then your program will hang. Similarly, if you use a plain socket to connect to a server's SSL socket, your application will hang. This is a characteristic of the protocol, and is not the fault of the LDAP provider. java.naming.ldap.version Specifies the protocol version for the provider. Two values are currently defined: 2 - selects LDAP Version 2 (LDAPv2) 3 - selects LDAP Version 3 (LDAPv3) For example, the following specifies that LDAPv3 should be used: env.put("java.naming.ldap.version", "3"); If this environment property has not been set then the provider will attempt to use LDAPv3 and will failover to LDAPv2. java.naming.ldap.attributes.binary Specifies attributes that have binary syntax. It extends the provider's list of known binary attributes. Its value is a string of space-separated attribute names. For example, the following setting informs the provider that the attribute named mpegVideo has binary syntax: env.put("java.naming.ldap.attributes.binary", "mpegVideo"); The values of attributes that have binary syntax are returned as byte arrays instead of Strings. If this environment property has not been set then only the following attributes are considered to have binary syntax: - attribute names containing ';binary' - photo (0.9.2342.19200300.100.1.7) - personalSignature (0.9.2342.19200300.100.1.53) - audio (0.9.2342.19200300.100.1.55) - jpegPhoto (0.9.2342.19200300.100.1.60) - javaSerializedData (1.3.6.1.4.1.42.2.27.4.1.7) - javaSerializedObject (1.3.6.1.4.1.42.2.27.4.1.2) - thumbnailPhoto (1.3.6.1.4.1.1466.101.120.35) - thumbnailLogo (1.3.6.1.4.1.1466.101.120.36) - userPassword (2.5.4.35) - userCertificate (2.5.4.36) - cACertificate (2.5.4.37) - authorityRevocationList (2.5.4.38) - certificateRevocationList (2.5.4.39) - crossCertificatePair (2.5.4.40) - x500UniqueIdentifier (2.5.4.45) java.naming.ldap.control.manageReferral Activates the ManageReferral control as defined in: http://ds.internic.net/internet-drafts/draft-ietf-ldapext-referral-00.txt Possible values are "true", "false". NOTE: Use of this property has been deprecated. You should not set this property explicitly. Use java.naming.referral instead, which automatically sends a manage referral control as needed. java.naming.ldap.deleteRDN Specifies whether the old RDN is removed during rename(). If the value is "true", the old RDN is removed; otherwise, the RDN is not removed. For example, the following specifies to delete the old RDN env.put("java.naming.ldap.deleteRDN", "true"); If this environment property has not been set then old RDNs are deleted from a entry during rename operations (i.e. default value is true). java.naming.ldap.derefAliases Specifies how aliases are dereferenced during search operations. The possible values are: always - always dereference aliases never - never dereference aliases finding - dereference aliases only during name resolution searching - dereference aliases only after name resolution For example: env.put("java.naming.ldap.derefAliases", "searching"); If this environment property has not been set then aliases are always de-referenced. NOTE: this environment property is unrelated to the dereference-links flag in the SearchControls object. java.naming.ldap.typesOnly Specifies whether only attribute types are to be returned during searches and getAttributes(). Its possible values are "true" or "false". For example, the following specifies that only types, not values are to be returned. env.put("java.naming.ldap.typesOnly", "true"); If this environment property has not been set then it indicates that the server should return both attribute types and values (i.e. default value is false). java.naming.ldap.ref.separator Specifies the character to use when encoding a RefAddr object in the javaReferenceAddress attribute (see the BINDINGS Section). This environment property should be used to avoid a conflict in the case where the default separator character appears in the components of a RefAddr object. For example, the following specifies that the separator ':' is to be used when storing RefAddr instances. env.put("java.naming.ldap.ref.separator", ":"); If unspecified, the default separator is the hash character '#'. java.naming.ldap.factory.socket Specifies the classname of a socket factory. This environment property is used to override the default socket factory. For example, the following specifies a socket factory to use: env.put("java.naming.ldap.factory.socket", "javax.net.ssl.SSLSocketFactory"); The class specified in this property must implement the interface javax.net.SocketFactory. See http://java.sun.com/security/ssl/API_users_guide.html for details. NOTE: if the security protocol environment property has been set but this property has not been set, then this property's value is set to "javax.net.ssl.SSLSocketFactory". java.naming.ldap.referral.limit Specifies the maximum number of referrals to follow in a chain of referrals. A setting of zero indicates that there is no limit. For example, the following specifies that the referral limit is 5. env.put("java.naming.ldap.referral.limit", "5"); If unspecified, the default limit is 10. java.naming.language NOTE: this environment property is currently ignored. com.sun.naming.ldap.trace.ber If the value of this property is an instance of java.io.OutputStream, trace information about BER buffers sent and received by the LDAP provider are written to that stream. If the value is null, no trace output is written. For example, env.put("com.sun.naming.ldap.trace.ber", System.err); sends the trace output to System.err. com.sun.naming.netscape.schemaBugs Netscape Directory Server 3.11 exports schema entries whose syntax is not compliant with RFC 2252. It also rejects some entries whose syntax is compliant. To update schema entries when using a Netscape Directory Server, you must set this property to "true" as follows: env.put("com.sun.naming.netscape.schemaBugs", "true"); If this property has not been set, the LDAP provider will write out schema entries that conform to RFC 2252. 4.0 NAMES & URLS ---------------- The syntax of names supplied to an LDAP context follows RFC-1779. Examples of such names are: dc=widget, dc=com o=widget, c=gb cn=John Smith, o=widget, c=gb The name supplied to an LDAP context is always relative to the context. For example, if you have an LDAP context (lctx) for "o=widget,c=gb", to name LDAP entries in that subtree, you would supply a name relative to "o=widget,c=gb". For example, to obtain the attributes for the entry "cn=John Smith" entry, you would do as follows: Attributes attrs = lctx.getAttributes("cn=John Smith"); Similarly, when you enumerate a context using any of the enumeration methods (list(), listBindings(), search()), the names you get back are relative to the target context--the context being enumerated. When there are referrals are invoked, instead of a relative name, you get back a LDAP URL string of the fully qualified name. You can supply names that follow RFC-1779 to any of the context operations. In addition, you can supply LDAP URLS (RFC-1959) without the search query to the initial context. When you do this, the host and port number to use for contacting the LDAP server is extracted from the URL supplied (i.e. the values of the java.naming.factory.initial and java.naming.provider.url environment or system properties are ignored). For example, InitialContext ictx = new InitialContext(); Attributes attrs = ictx.getAttributes( "ldap://wserver:389/cn=John Smith, o=widget, c=gb"); 5.0 ATTRIBUTES -------------- Some LDAP servers support attribute subclassing, attribute name synonyms, and language codes for specifying language preferences for attribute values. In such cases, you should be aware that the server might give you back attributes with names different than what you asked for. In LDAP, attribute names are case-insensitive. Therefore, when you are creating a collection of attributes to be passed as parameters to JNDI operations, it is best if you use case-insensitive Attributes. You can create a case-insensitive Attributes using BasicAttributes as follows: Attributes attrs = new BasicAttributes(true); // ignoreCase=true The LDAP provider expects as input and returns as output all attribute values as either String or byte[]. See the java.naming.ldap.attributes.binary environment property for which ones are treated as byte[] and how to add user-defined binary attributes to the list. For all attribute values, regardless of whether they are binary, you need to know the syntax and format of the attribute value. You can typically find this out by reading the schema document in which the attribute and its syntax is defined. When attributes are supplied as arguments to JNDI calls then they must satisfy whatever schema is enforced at the LDAP directory. In particular, the "objectClass" attribute is normally required when you are creating a new LDAP entry (such as when you use bind(), rebind() or createSubcontext()). 6.0 API MAPPINGS ---------------- The LDAP service provider provides a class, LdapCtx, that implements the DirContext interface. DirContext methods are mapped onto LDAP operations as described below. addToEnvironment() This method allows you to modify an environment property of a context. When you modify any of the following properties of a context, the context's behavior will change according to the new property. java.naming.batchsize java.naming.ldap.deleteRDN java.naming.ldap.derefAliases java.naming.ldap.ref.separator java.naming.ldap.referral.limit java.naming.ldap.typesOnly java.naming.referral (*) java.naming.security.protocol (*) java.naming.security.authentication (*) java.naming.security.principal (*) java.naming.security.credentials (*) java.naming.ldap.version (*) java.naming.ldap.attributes.binary (*) java.naming.ldap.control.manageReferral (*) java.naming.ldap.factory.socket (*) (*) If this property is changed, a new connection will be created the next time the service provider communicates with the LDAP server. Supplying null for the property value has the same effect as removing the property. For all other environment properties, the new property is recorded but the context is not affected. For example, if you specify a new value for java.naming.provider.url, the context will record the new property but do not expect that the context will create a new connection to the server. If you want a new connection using a new URL, you should create a new initial context using the new URL. bind() An LDAP add operation is performed to create the named entry and its associated attributes (see the ATTRIBUTES Section). If an object is provided in the arguments to bind() then it is converted into attributes and stored in the entry along with any supplied attributes. See the BINDINGS Section for details. close() If the connection being used by this context is not shared with another context, any outstanding requests are abandoned and the connection is unbound from the server. composeName() Concatenates names according to the LDAP name syntax described in getNameParser() below. createSubcontext() An LDAP add operation is performed to create the named entry and its associated attributes. If no attributes are supplied then the objectClass attribute is generated with the single value "top". destroySubcontext() An LDAP delete operation is performed to remove the named entry and its associated attributes. The named entry must be a leaf entry; subtrees are not removed. If the leaf entry does not exist (but its parents exist), the operation still succeeds. getAttributes() An LDAP search operation is performed to retrieve the LDAP entry's attributes. getEnvironment() Returns the environment properties in effect at the context. getNameParser() LDAP names are comma-separated and ordered right-to-left (little-endian). Each namepart is an equals-separated type/value pair. Case is ignored. A character is escaped by preceding it by a backslash. Characters are quoted using double-quotes. Additional spaces are ignored. getSchema() See the SCHEMA Section below. getSchemaClassDefinition() See the SCHEMA Section below. list() An LDAP one-level search operation is performed to retrieve the names of the entries immediately below the named entry. The names which are returned are either relative to the named context or they are LDAP URLs. listBindings() An LDAP one-level search operation is performed below the named entry to retrieve the attributes representing objects (or object references). If object or reference attributes are present then they are used to assemble the original objects using NamingManager.getObjectInstance(). If none are present then LdapCtx objects are assembled instead and returned. The names which are returned are either relative to the named context or they are LDAP URLs. lookup() lookupLink() An LDAP base-object search operation is performed at the named entry to retrieve the attributes representing an object (or an object reference). If object or reference attributes are present then they are used to assemble the original object using NamingManager.getObjectInstance(). If none are present then an LdapCtx object is assembled and returned. modifyAttributes() An LDAP modify operation is performed at the named entry using the supplied modifications. The operation is performed atomically. removeFromEnvironment() This method allows you to remove a environment property from a context. When you remove any of the following properties, the context's behavior will assume the property's default value as described in the ENVIRONMENT PROPERTIES Section. For example, removing java.naming.batchsize will cause the context to use the default batch size of 1. java.naming.batchsize java.naming.ldap.deleteRDN java.naming.ldap.derefAliases java.naming.ldap.policies java.naming.ldap.ref.separator java.naming.ldap.referral.limit java.naming.ldap.typesOnly java.naming.referral (*) java.naming.security.protocol (*) java.naming.security.authentication (*) java.naming.security.principal (*) java.naming.security.credentials (*) java.naming.ldap.version (*) java.naming.ldap.attributes.binary (*) java.naming.ldap.control.manageReferral (*) java.naming.ldap.factory.socket (*) (*) If this property is removed, a new connection will be created the next time the service provider communicates with the LDAP server. For all other environment properties, the removal is recorded but the context is not affected. For example, if you remove the java.naming.provider.url property, the context will remove the property from the environment but do not expect that the context will create a new connection using the default URL ("ldap://localhost:389/"). rebind() This method is like bind() except if an entry with the same name already exists in the directory, and you are not changing the attributes, the attributes of the old entry remain unchanged. This method uses the LDAP delete operation to get rid of any original entry and the LDAP add operation to add the updated entry. If an object is provided in the arguments to rebind() then it is converted into attributes and stored in the entry along with any supplied attributes. See the BINDINGS Section for details. rename() An LDAP modify DN operation is performed to rename the entry. If LDAPv2 is being used then the new name and the old name must share the same immediate parent name. search() An LDAP search operation is performed according to the specified search controls. If objects should be returned then the attributes representing objects (or object references) are requested. If these attributes are present then they are used to assemble the original objects using NamingManager.getObjectInstance(). If none are present then LdapCtx objects are assembled instead and returned. The names which are returned are either relative to the named context or they are LDAP URLs. NOTE: an LDAP compare operation is performed instead of an LDAP search when a JNDI search filter is suitably constrained. unbind() An LDAP delete operation is performed to remove the named entry. The named entry must be a leaf entry; subtrees are not removed. 7.0 BINDINGS ------------ Objects are bound to names in the directory service by calling the bind()/rebind() methods. A Reference to an object, or an instance of a Serializable object, a java.rmi.Remote object, or a DirContext object, may be bound. Objects are retrieved from the directory service by calling lookup(), listBindings() or search(). A Reference contains the information necessary to construct the object being referenced, including where to load the class file (byte codes) for the object. The serialized form of the object, however, contains the state of the object. A RMI remote object is represented in the directory using its RMI name (i.e., the RMI url that identifies the RMI registry in which it is bound and the object within the registry). The JNDI client looking up a serialized object must have access to the class file of the object, either, by including it in the program's classpath, or having access to the object's codebase that is recorded in the directory. (See SECURITY CONSIDERATIONS Section). 7.1 How Objects Are Stored The LDAP service provider follows the Internet-Draft draft-ryan-java-schema-01.txt (also distributed with this release) for storing objects into the LDAP directory. It supports storing Remote, Serializable or Referenceable objects (or an object that is instance of Reference). Details of how these objects are stored in the directory are supplied in the Internet-Draft. In addition, the LDAP provider also supports storing DirContext objects. In this case, getAttributes() is invoked on the DirContext object and those attributes are stored. When storing a Reference's list of RefAddr into the javaReferenceAddress attribute, the separator to use for delimiting the address's position, type and content are controlled using the environment property java.naming.ldap.ref.separator. If this environment property is not specified, the hash character '#' is used as the separator. 7.2 Schema Definitions To Support Storing Objects The schema for storing objects in the LDAP directory are described in the Internet-Draft draft-ryan-java-schema-01.txt. 8.0 SCHEMA ---------- The DirContext returned by DirContext.getSchema() has the same hierarchical structure described in the JNDI API document. On an LDAP server, schema are stored as a set of attribute values in the "subschema" entry. getSchema() uses this set of values to construct a corresponding schema tree. Any modification made to the schema tree triggers a change on the server's "subschema" entry and may throw an exception if the change violates the server's rules. The root of the schema tree has four children: AttributeDefinition ClassDefinition SyntaxDefinition MatchingRule Each of these children has a child for each corresponding schema definition on the server. "AttributeDefinition" has a child for each value of the "attributeTypes" attribute of the server's "subschema" entry. "ClassDefinition" has a child for each value of the "objectClasses" attribute of the server's "subschema" entry. "SyntaxDefinition" has a child for each value of the "ldapSyntaxes" attribute of the server's "subschema" entry. "MatchingRule" has a child for each value of the "matchingRules" attribute of the server's "subschema" entry. These children are the leaves of the schema tree. Each child contains attributes that describe their particular definition (see the table below). The attributes for these schema have a 1-to-1 correspondence with the names defined in RFC-2252 for AttributeTypeDescription, ObjectClassDescription, SyntaxDescription and MatchingRuleDescription. Just like the tags in the descriptions, only the NUMERICOID attribute is required, the rest are optional (except for MatchingRuleDescription where the SYNTAX attribute is also mandatory). The values for all attributes in the schema tree are simple strings (or in LDAP parlance "directory strings"). The following are the attribute IDs and values that objects in the AttributeDefinition schema tree can have. They correspond directly to the AttributeTypeDescriptions in RFC-2252: ATTR ID VALUE DESCRIPTION -------------- ----------------------------- NUMERICOID unique identifier (required) NAME attribute's name DESC attribute's description OBSOLETE value = "true" if obsolete, otherwise non-existent SUP superior the attribute's type is derived from EQUALITY value = name/OID of equality matching rule, non-existent if equality matching not allowed ORDERING value = name/OID of ordering matching rule, otherwise non-existent if ordering matching not allowed SUBSTRING value = name/OID of substring matching rule, otherwise non-existent if substring matching not allowed SYNTAX numeric OID of the syntax of values of this type SINGLE-VALUE value = "true" if attribute not multi-valued otherwise non-existent COLLECTIVE value = "true" if attribute is collective otherwise non-existent NO-USER-MODIFICATION value = "true" if not user-modifiable, otherwise non-existent USAGE attribute usage The following are the attribute IDs and values that objects in the ClassDefinition schema tree can have. They correspond directly to the ObjectClassDescriptions in RFC-2252: ATTR ID VALUE DESCRIPTION -------------- ----------------------------- NUMERICOID unique identifier (required) NAME class's name DESC class's description OBSOLETE value = "true" if obsolete, otherwise non-existent SUP superior the class's type is derived from ABSTRACT STRUCTURAL AUXILIARY one of these three attributes will be present to indicate the kind of objectclass this is. The other two attributes will not be present. The value of the attribute that is present will be "true". MUST A list of Attribute IDs that must be present MAY A list of Attribute IDs that may be present The following are the attribute IDs and values that objects in the SyntaxDefinition schema tree can have. They correspond directly to the SyntaxDescriptions in RFC-2252: ATTR ID VALUE DESCRIPTION -------------- ----------------------------- NUMERICOID unique identifier (required) DESC syntax's description The following are the attribute IDs and values that objects in the MatchingRule schema tree can have. They correspond directly to the MatchingRuleDescriptions in RFC-2252: ATTR ID VALUE DESCRIPTION -------------- ----------------------------- NUMERICOID unique identifier (required) NAME matching rule's name DESC matching rule's description OBSOLETE value = "true" if obsolete, otherwise non-existent SYNTAX numeric OID of the syntax to which this matching rule applies The schema tree can be searched, modified and traversed like any other DirContext. The tree's name syntax is left-to-right slash-separated. If a child entry has a NAME attribute, it is used as the entry's name; otherwise, its NUMERICOID is used as the name. Examples: The following code fragment is used to get the attributes for the LDAP attribute definition of "cn": DirContext schemaCtx = ctx.getSchema(""); Attributes cnDesc = schemaCtx.getAttributes("AttributeDefinition/cn"); Using this result, you can get the LDAP syntax attribute for "cn" as follows: String syntax = cnDesc.get("SYNTAX"); To get the LDAP attribute definition for an LDAP attribute which is unnamed but has "1.2.3.4.5" as its numeric OID: DirContext schemaCtx = ctx.getSchema(""); DirContext cnDefn = schemaCtx.lookup("AttributeDefinition/1.2.3.4.5"); The following JNDI methods are implemented by searching the schema tree for the appropriate entries: DirContext.getSchemaClassDefinition() Attribute.getAttributeDefinition() Attribute.getAttributeSyntaxDefinition() 9.0 SECURITY CONSIDERATIONS --------------------------- 9.1 JDK 1.1 When a Reference or Serializable object is read from the directory, a codebase specifying where to load the classes for the object may be stored as one of the object's attributes. If the classes are not included in the program's classpath, the LDAP provider will attempt to load these classes using the RMIClassLoader. Using this feature requires the application to install a SecurityManager. For example, you can install the RMISecurityManager as follows: System.setSecurityManager(new java.rmi.RMISecurityManager()); 9.1 Java 2 Platform Version 1.2 When using the LDAP service provider with a SecurityManager installed in the Java 2 Platform Version 1.2, you must grant the LDAP service provider (ldap.jar, providerutil.jar) the following permissions: permission java.util.PropertyPermission "java.naming.provider.url", "read"; permission java.net.SocketPermission "host[:port]", "connect"; For connecting to the host/port identified in Context.PROVIDER_URL and in URL string names supplied to context methods. permission java.net.SocketPermission "host[:port]", "connect,accept"; For hosts and ports named in the URL strings in References and "javaCodebase" attributes stored with Serializable objects. permission java.lang.RuntimePermission "getClassLoader"; If the class loader that loaded the LDAP service provider is neither the same nor an ancestor of the class loader of the caller of JNDI methods. You must grant the JNDI (jndi.jar) the following permissions: permission java.util.PropertyPermission "java.naming.factory.initial", "read"; permission java.util.PropertyPermission "java.naming.factory.object", "read"; permission java.util.PropertyPermission "java.naming.factory.url.pkgs", "read"; permission java.lang.RuntimePermission "getClassLoader"; If the class loader that loaded JNDI is neither the same nor an ancestor of the class loader of the caller of JNDI methods. Plus all of the permissions granted to the LDAP service provider except for the PropertyPermission for "java.naming.provider.url". [The LDAP service provider accesses this property inside a doPrivileged block.] You must grant to the application using JNDI and the LDAP service provider all of the permissions granted to JNDI and the LDAP service provider except for the PropertyPermissions. [JNDI and the LDAP provider access these properties inside a doPrivileged block.] Note: If JNDI and the LDAP service provider are installed in the jre/lib/ext directory, they are by default granted "AllPermission" and the permissions mentioned for them need not be explicitly granted. In this common scenario, you would only have to deal with the permissions listed for the application code, object factories, and your own service providers.