Whole document tree JNDI Implementor Guidelines for LDAP Service ProvidersDraft 0.3Please send feedback to jndi@java.sun.com
1. IntroductionThis document specifies guidelines that developers creating LDAP service providers and service providers that support LDAP-like features should follow. By following these guidelines, developers can produce implementations that JNDI API users can configure and use with minimal differences.Not all of the features described in this document must be supported by an LDAP service provider. However, if a feature is supported, it should be supported in the way described by this document.
2. ConformanceAn LDAP service provider that supports LDAP version 3 (LDAPv3) conforms to:
3. Environment PropertiesEnvironment properties are the means by which JNDI application users configure and affect the behavior of JNDI service providers. Consequently, service providers must interpret and handle environment properties in the same way.There are four types of environment properties that affect LDAP service providers:
3.1 Overview3.1.1 InitializationWhen creating an initial context, environment properties can be passed as an argument to the constructor or may be initialized as specified in the JNDI documentation.In particular, if any of the following properties is not supplied in the environment properties then it is sought from the system properties, applet parameters, and both provider and application resource files (in that order):
A context's environment properties can be examined using the Context.getEnvironment method. 3.1.2 ModificationA context's environment properties may be changed using the Context.addToEnvironment and Context.removeFromEnvironment methods.3.1.3 ScopeWith the exception of the java.naming.provider.url and java.naming.factory.initial properties, changing a property using the Context.addToEnvironment or Context.removeFromEnvironment methods affects the context instance on which the method is invoked. For example, if you specify new credentials for a context to use, subsequent methods invoked on that context that require communication with the server will use those new credentials (perhaps internally by first creating a new connection to the server). These updated environment properties are inherited by context instances that are subsequently derived from the affected context instance, but do not otherwise affect other context instances that were in existence prior to the update.3.1.4 TimelinessWhen a change is made to the environment properties, there is no requirement that the change be verified and acted upon at the time the Context.addToEnvironment or Context.removeFromEnvironment method is invoked. The only requirement is that the change (or changes) be effective the next time an operation that uses that property is invoked.3.1.5 DefaultsThis specification defines defaults for the environment properties. In a few cases, the default is determined by the service provider. If a context does not have a particular environment property, it behaves as if it has that environment property with its default value.When a property is removed from the environment properties of a context, the context assumes the default behavior specified for that property. This does not necessarily mean that the default value must be recorded as the property's value. The removal may also be indicated by the absence of the property from the context's environment properties. 3.1.6 Acceptable ValuesThis specification defines acceptable values for the environment properties. Some environment properties have a fixed set of acceptable values while others have values that must follow a particular syntax. If an unacceptable value is presented, a property-specific exception will be thrown (for example, ConfigurationException, IllegalArgumentException, or AuthenticationNotSupportedException). In some cases, it might be reasonable for the service provider to accept additional values than those specified, in which case, those values should be documented.3.2 JNDI PropertiesLDAP service providers should process the JNDI environment properties according to the following specifications. In the examples given, env is an instance of Hashtable that holds the environment properties used to create an initial context.The value of this property is a string of decimal digits that specifies the batch size of search results returned by the server. The value of this property is a colon-separated list of fully qualified class names of control factory classes. The value of this property is the fully qualified class name of the factory class which creates the initial context for the LDAP service provider. The value of this property is a colon-separated list of fully qualified class names of object factory classes. The value of this property is a colon-separated list of fully qualified class names of state factory classes. The value of this property is a string language tag according to RFC 1766.
The affect of this property is implementation-specific. No default value is defined. For example: env.put(Context.LANGUAGE, "ja-JP"); The value of this property is a URL string that specifies the hostname and port number of the LDAP server, and the root distinguished name of the naming context to use. The value of this property is a string that specifies how referrals shall be handled by the provider. The following values are defined for this property:
See LDAP URL for information on how to treat multiple URLs found in a single referral entry. If this property is not set then its default value is ignore. For example: env.put(Context.REFERRAL, "throw"); The value of this property is a string that specifies the authentication mechanism(s) for the provider to use. The following values are defined for this property:
See the SASL section for information on how this property is used for SASL authentication. See RFC 2829 for information on LDAP authentication mechanisms. If this property is not set then its default value is none, unless the java.naming.security.credentials property is set, in which case the default value is simple. If this property is set to a value that the provider does not recognize or support, it should throw AuthenticationNotSupportedException. For example: env.put(Context.SECURITY_AUTHENTICATION, "simple"); env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5 CRAM-MD5");
For anonymous binds, this property is ignored - an empty string is always used for the credentials. For simple authentication and SASL authentication that requires a password, the value of this property may be supplied as a java.lang.String, a char[] or a byte[]. If it is a String or a char[] then it is encoded into a byte array using UTF-8 in the case of LDAPv3 and encoded using ISO-Latin-1 in the case of LDAPv2. If it is a byte[] then it is used as is. See the SASL section for information on how this property is used for SASL authentication. No default value is defined for this property. For example: env.put(Context.SECURITY_CREDENTIALS, "secret"); The value of this property is a string that specifies the identity of the principal to be authenticated. Its format depends on the authentication type; see RFC 2829 for more information. The value is used as the name component in an LDAP ASN.1 BindRequest for non-SASL authentication. For SASL authentication, the value of this property is used as the authentication ID for SASL mechanisms that need an authentication ID.
If this property is set to ssl, the provider must use SSL sockets, or throw ConfigurationException if it is unable to do so. In addition to the value listed above, a provider may support other security protocols. However, such provider-specific protocols might not be supported by all providers. If this property is set to a security protocol that the provider does not recognize or support, it should throw ConfigurationException. If the java.naming.ldap.factory.socket property is set, then the socket factory identified by that property must create sockets that are appropriate for this protocol setting. For example, if the security protocol is set to ssl, then the socket factory must create SSL-compliant sockets. If this property is not set then the default is to use no security protocol. As a developer of the LDAP provider, you should be aware that using SSL to connect to a server on a port that is not listening for SSL connections causes the socket to hang. Similarly, using a plain socket to connect to a server that is listening for SSL connections also leads to hanging. This is a characteristic of the protocol that some implementations may choose to correct but is not otherwise required to do so. The provider's documentation, however, should describe this behavior to its users. See SSL for information on how to use SSL. For example: env.put(Context.SECURITY_PROTOCOL, "ssl"); 3.3 LDAP-specific PropertiesLDAP-specific properties are environment properties that apply to LDAP service providers in general. These properties' names have the prefix "java.naming.ldap.". The following table lists LDAP-specific properties that have been defined so far. If there is a property that you feel belongs on this list, please send a description of it to jndi@java.sun.com.
No default is defined. If this property is not set then only the following attributes are considered to have non-string syntax:
env.put("java.naming.ldap.attributes.binary", "mpegVideo myspecialkey");
No default value is defined for this property. For example: env.put("java.naming.ldap.control.connect", new Control[]{ new ManageReferralControl(true) });
For example: env.put("java.naming.ldap.deleteRDN", "false"); The value of this property is a string that specifies how aliases are dereferenced during search operations. The following values are defined for this property:
This property is used to override the default socket factory. The class specified in this property must implement the javax.net.SocketFactory interface. See http://java.sun.com/products/jsse/doc/guide/API_users_guide.html for more information. See SSL for information on how to use SSL. In addition, if the java.naming.security.protocol property is set, then the socket factory identified by this property must create sockets which are appropriate for that protocol setting. For example, if the security protocol is set to ssl then the socket factory must create SSL-compliant sockets. No default is defined for this property. For example: env.put("java.naming.ldap.factory.socket", "javax.net.ssl.SSLSocketFactory");
This property is used to avoid a conflict in the case where the default separator character appears in the components of a RefAddr object. If this property is not set then its default value is '#' (the hash character). For example: env.put("java.naming.ldap.ref.separator", ":");
If this property is not set then the default value is 10. For example: env.put("java.naming.ldap.referral.limit", "5");
If this property is not set then its default value is false. For example: env.put("java.naming.ldap.typesOnly", "true");
If this property is not set then the provider first attempts to bind using LDAP v3 and fails over to using LDAP v2 if a protocol error is received from the server. This failover mechanism is only used when the java.naming.security.authentication property indicates anonymous bind or simple authentication. For example: env.put("java.naming.ldap.version", "2"); 3.4 Feature-specific PropertiesFeature-specific properties are environment properties which apply to a particular feature which is supported by a provider.3.4.1 SASL PropertiesThere are two groups of SASL properties. The first group comprises those that relate to how the JNDI service provider interacts with the Java SASL API. These properties have the prefix "java.naming.security.sasl." The second group comprises those that affect the SASL mechanisms. These properties are specified in the Java SASL API (draft-weltman-java-sasl-05.txt) and have the prefix "javax.security.sasl." See the SASL section and the Java SASL API for details about this second group of properties.java.naming.security.sasl.authorizationId The value of this property is a string that specifies the authorization ID for the SASL mechanisms. java.naming.security.sasl.realm The value of this property is a string that specifies the realm information required by some SASL mechanisms such as DIGEST-MD5.
The value of this property is an instance of javax.security.auth.callback.CallbackHandler. When the provider uses a SASL mechanism that requires callbacks, the SASL mechanism uses the object supplied in the property. The callback handler should satisfy a NameCallback by supplying the authentication ID. javax.security.sasl.client.pkgs The value of this property is a '|'-separated list of package names used to locate factories that produce SASL mechanism drivers. javax.security.sasl.qop The value of this property is a ','-separated list of quality-of-protection (qop) values used to specify the client's qop preference. A qop value is one of javax.security.sasl.strength The value of this property is a ','-separated list of cipher strength values used to specify the client's preference. A strength value is one of javax.security.sasl.maxbuffer The value of this property is the string representation of an integer that specifies the maximum size of the receive buffer in bytes that the client is willing to receive. If this property is absent, the default size is defined by the SASL mechanism. javax.security.sasl.server.authentication The value of this property is either "true" or "false", specifying whether the server must authenticate to the client or not, respectively. If this property is absent, the default is "false". javax.security.sasl.policy.forward The value of this property is either "true" or "false", specifying whether the selected SASL mechanism must support forward secrecy between sessions or not, respectively. If this property is absent, the default is "false". javax.security.sasl.policy.credentials The value of this property is either "true" or "false", specifying whether the selected SASL mechanism must require client credentials or not, respectively. If this property is absent, the default is "false". javax.security.sasl.policy.noplaintext The value of this property is either "true" or "false", specifying whether the selected SASL mechanism must not be susceptible to simple plain passive attacks or not, respectively. If this property is absent, the default is "false". javax.security.sasl.policy.noactive The value of this property is either "true" or "false", specifying whether the selected SASL mechanism must not be susceptible to active (non-dictionary) attacks or not, respectively. If this property is absent, the default is "false". javax.security.sasl.policy.nodictionary The value of this property is either "true" or "false", specifying whether the selected SASL mechanism must not be susceptible to dictionary attacks or not, respectively. If this property is absent, the default is "false". javax.security.sasl.policy.noanonymous The value of this property is either "true" or "false", specifying whether the selected SASL mechanism must not accept anonymous logins or not, respectively. If this property is absent, the default is "false". 3.5 Provider-specific PropertiesProvider-specific properties are environment properties which apply only to particular provider implementations. The names of these properties are chosen by the provider's implementor. The recommended policy for naming these properties is to use the implementor's reversed DNS domain name to prefix the provider's package name and to use that package name to prefix the property name. For example, Sun prefixes its provider-specific LDAP properties with "com.sun.jndi.ldap".
4. NamesNames are handled by the provider's context methods according to the following rules:
The name supplied to an LDAP context is always relative to that context. For example, given an LDAP context (lctx) for "dc=widget,dc=com", in order to name LDAP entries in that subtree, a name relative to "dc=widget,dc=com" must be supplied. For example, the following call obtains the attributes for the "cn=John Smith,dc=widget,dc=com" entry, Attributes attrs = lctx.getAttributes("cn=John Smith"); Similarly, when a context is enumerated using any of the enumeration methods (Context.list, Context.listBindings, DirContext.search), the names returned are relative to the target context--the context being enumerated. When referrals are invoked, instead of a relative name, an LDAP URL string, containing the fully qualified name, is returned. The format of LDAP URLs is defined in RFC 2255. LDAP URLs that follow RFC 2255 may be supplied to any of the context methods. The hostname and port number are extracted from the URL and used to contact the LDAP server; the java.naming.factory.initial and java.naming.provider.url properties are ignored. For example, DirContext ictx = new InitialDirContext();
This code fragment contacts the LDAP server at machine wserver at port 389.
5. AttributesThe LDAP provider expects as input and returns as output all attribute values as either String or byte[] objects. See the java.naming.ldap.attributes.binary environment property for which ones are treated as byte[] and how to extend the list.
6. URLsRFC 2255 describes the syntactic format of LDAP URLs. The format contains all the elements necessary to specify an LDAP search operation, with provisions for supporting extensions:Authentication information may be specified in the extensions portion of the URL. See the RFC for a complete description of the format.ldap://host:port/dn?attributes?scope?filter?extensions URLs play a role in several places in JNDI:
To configure an LDAP service provider, you typically supply an LDAP URL in the java.naming.provider.url property. This is used by the LDAP service provider to configure its connection to the directory server. Only the host, port, and dn parts of the URL are relevant in this setting. Supplying other parts of the URL results in a ConfigurationException. If a URL string (with syntax scheme_id:rest_of_name) is passed to the methods in InitialContext, either as a String argument or as the first component of Name, the URL's scheme id is used to locate the context factory for handling that scheme. If none is found, the URL string is treated as an ordinary name and passed to the initial context specified by the java.naming.factory.initial property is used. See the java.naming.spi.NamingManager.getURLContext method for details on how URL context factories are located. Note that this support for LDAP URLs as names is only available in the initial context. With the exception of the search methods, when an LDAP URL
is passed as a name to the initial context, the URL should not contain
any query ('?') components. Otherwise, an InvalidNameException
is thrown by the service provider. For the search methods, the query
components of the URL override any corresponding components supplied as
arguments. For example, if an LDAP URL containing a scope component is
supplied, then that scope overrides any scope setting that may be passed
in a SearchControls argument.
An LDAP referral contains a list of one or more URLs. To process an LDAP referral (either explicitly or implicitly by setting the java.naming.referral property), the service provider needs to use the information in the these URLs to create connections to LDAP servers to which they refer. When multiple LDAP URLs are present in a single referral they are treated as alternatives and each is followed until one succeeds. The complete URL (that is, including any query components) are used. When the name of the entry being returned has a name that is not relative to the target context (i.e., the starting context for the list or search), the name is returned as a URL. See the NameClassPair.isRelative method for details. When an LDAP namespace is federated underneath another namespace (for example, such as DNS), the information that is stored in the superior namespace might be an LDAP URL. In such a scenario, a lookup/list/search operation in the superior namespace would return a Reference containing an LDAP URL for the LDAP namespace. The service provider for the superior namespace would pass the Reference to the getObjectInstance method to create an instance of an LDAP context. 7. Java Objects7.1 StoringThe LDAP provider should support the storing of Java objects into the directory. This is implemented in the following methods:
References, referenceable and serializable objects should be stored according to RFC 2713. DirContext objects should be stored by storing their attributes. 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 '#' should be used as the separator. The provider uses the DirectoryManager.getStateToBind method when storing objects in the directory. This allows objects of any type to be transformed into one of the four categories listed above so that they can be stored into the directory. 7.2 ReadingObjects are read from the directory using the following operations:
8.0 SchemaJNDI does not specify schema-related details such as structure and contents of the schema tree, permission to modify to the contents of the schema tree, and the effect of such modifications on the directory are dependent on the underlying directory. JNDI specifies only that the root schema context--that returned by DirContext.getSchema()--contain the following bindings:
Permission to modify the contents of the schema tree is determined by the directory administrator. When the schema tree is modified, the changes are made to schema stored on the directory server. 8.1 Schema Tree StructureIn addition to the three bindings in the root schema context listed previously, the root schema context may also contain the following four bindings:
Any or all of these bindings may be absent if the underlying directory does not publish such schema information, or the service provider does not support retrieving them. If these names are present in the root schema context, however, they must have the binding specified in the above table. The attribute names and values of these entries' attributes are case-insensitive.
8.2 Attribute DefinitionsThe name "AttributeDefinition" is bound to a context containing DirContext objects representing attribute definitions in the schema. For example, if a directory supports a "commonName" attribute, the "AttributeDefinition" context would have a binding with name "commonName" that is bound to a DirContext object.Each object in the "AttributeDefinition" context has the following mandatory
and optional attributes:
These attributes have a 1-to-1 correspondence with the names defined in RFC 2252 for "AttributeTypeDescription." All the attribute values are represented by the java.lang.String class. You can, for example, obtain the object representing the "cn" attribute using the following code: If you then get the attributes of the "cnSchema" DirContext object, you would see:DirContext schema = ctx.getSchema(""); // get schema tree DirContext cnSchema = schema.lookup("AttributeDefinition/cn"); An equivalent way of getting "cnSchema" is if you already have a "cn" attribute. The following code illustrates this alternative:NUMERICOID 2.5.4.3 NAME cn SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 DESC Standard Attribute, alias for commonName Attributes attrs = ctx.getAttributes("cn=John", new String[]{"cn"}); Attribute cnAttr = attrs.get("cn"); DirContext cnSchema = cnAttr.getAttributeDefinition(); 8.3 Object Class DefinitionsThe name "ClassDefinition" is bound to a context containing DirContext objects representing object class definitions in the schema. For example, if a directory supports a "country" object class, the "ClassDefinition" context would have a binding with name "country" that is bound to a DirContext object.Each object in the "ClassDefinition" context has the following mandatory
and optional attributes:
These attributes have a 1-to-1 correspondence with the names defined in RFC 2252 for "ObjectClassDescription." All the attribute values are represented by the java.lang.String class. You can, for example, obtain the object representing the "country" object class using the following code: If you then get the attributes of the "countrySchema" DirContext object, you would see:DirContext schema = ctx.getSchema(""); // get schema tree DirContext countrySchema = schema.lookup("ClassDefinition/country"); An equivalent way of getting "countrySchema" is if you already have a "country" object. The following code illustrates this alternative:NUMERICOID 2.5.6.2 NAME country MAY aci, searchguide, description MUST objectclass, c DESC Standard ObjectClass SUP top Note: JNDI 1.1's specification of getSchemaClassDefinition() implies that the service provider should return any one of an object's object class definitions. This specification is inadequate because an object usually has multiple object classes and the application might require knowledge about any of those object classes depending on what it is doing. The proposal as illustrated by the example above is to return a context containing all of the object class definitions.// Read object from directory DirContext countryObj = (DirContext)ctx.lookup("c=us", new String[]{"country"}); // Get all of object's object class definitions DirContext objClasses = countryAttr.getSchemaClassDefinition(); // Pick out "country" object class in particular DirContext countryClass = (DirContext)objClasses.lookup("country"); 8.4 Syntax DefinitionsThe name "SyntaxDefinition" is bound to a context containing DirContext objects representing syntax definitions in the schema. For example, if a directory supports the "1.3.6.1.4.1.1466.115.121.1.15" syntax (Directory String) syntax, the "SyntaxDefinition" context would have a binding with name "1.3.6.1.4.1.1466.115.121.1.15" that is bound to a DirContext object.Each object in "SyntaxDefinition" context has the following mandatory
and optional attributes:
These attributes have a 1-to-1 correspondence with the names defined in RFC 2252 for "SyntaxDescription." All the attribute values are represented by the java.lang.String class. You can, for example, obtain the object representing the "1.3.6.1.4.1.1466.115.121.1.15" syntax using the following code: If you then get the attributes of the "dirStringSchema" DirContext object, you would see:DirContext schema = ctx.getSchema(""); // get schema tree DirContext dirStringSchema = schema.lookup("SyntaxDefinition/1.3.6.1.4.1.1466.115.121.1.15"); An equivalent way of getting "dirStringSchema" is if you already have an attribute that has that syntax (such as, the "country" attribute). The following code illustrates this alternative:NUMERICOID 1.3.6.1.4.1.1466.115.121.1.15 DESC Directory String Attributes attrs = ctx.getAttributes("c=us", new String[]{"country"}); Attribute countryAttr = attrs.get("country"); DirContext dirStringSchema = countryAttr.getSyntaxAttributeDefinition(); 8.5 Matching RulesThe name "MatchingRule" is bound to a context containing DirContext objects representing matching rules in the schema. A "matching rule" uniquely identifies the algorithm to use when comparing attribute values. For example, a directory might support a matching rule that is based on how a string sounds and define it as the "soundAlikeMatch" matching rule. Then, the "MatchingRule" context would have a binding with name "soundAlikeMatch" that is bound to a DirContext object.When a matching rule is an extensible matching rule, it must also contain an "APPLIES" attribute listing the attributes to which this extensible matching rule can be applied. Each object in "MatchingRule" context has the following mandatory and
optional attributes:
These attributes have a 1-to-1 correspondence with the names defined in RFC 2252 for "MatchingRuleDescription" and "MatchingRuleUseDescription." All the attribute values are represented by the java.lang.String class. You can, for example, obtain the object representing the "soundAlikeMatch" syntax using the following code: If you then get the attributes of the "soundMatchSchema" DirContext object, you would see:DirContext schema = ctx.getSchema(""); // get schema tree DirContext soundMatchSchema = schema.lookup("MatchingRule/soundAlikeMatch"); NUMERICOID 1.2.3.4.5 NAME soundAlikeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (for directory string) APPLIES 2.5.4.41, 2.5.4.15 DESC Home-grown Phonetic match 8.6 Extension DefinitionsThe name "ExtensionDefinition" is bound to a context containing DirContext objects representing extensions supported by the server. For example, a directory might support the "Start TLS" extension ("1.3.6.1.4.1.1466.20037"). Then, the "ExtensionDefinition" context would have a binding with name "1.3.6.1.4.1.1466.20037" that is bound to a DirContext object.Each object in "ExtensionDefinition" context has the following mandatory
and optional attributes:
All the attribute values are represented by the java.lang.String class. You can, for example, obtain the object representing the Start TLS extension ("1.3.6.1.4.1.1466.20037") using the following code: If you then get the attributes of the "startTLSSchema" DirContext object, you would see:DirContext schema = ctx.getSchema(""); // get schema tree DirContext startTLSSchema = schema.lookup("ExtensionDefinition/1.3.6.1.4.1.1466.20037"); NUMERICOID 1.3.6.1.4.1.1466.20037 DESC Start TLS (see RFC 2830) 8.7 Control DefinitionsThe name "ControlDefinition" is bound to a context containing DirContext objects representing controls supported by the server. For example, a directory might support the control for asking the server to sort the search results it returns.Each object in "ControlDefinition" context has the following mandatory
and optional attributes:
All the attribute values are represented by the java.lang.String class. You can, for example, obtain the object representing the server-side sorting control ("1.2.840.113556.1.4.473") using the following code: If you then get the attributes of the "svrSortSchema" DirContext object, you would see:DirContext schema = ctx.getSchema(""); // get schema tree DirContext svrSortSchema = schema.lookup("ControlDefinition/1.2.840.113556.1.4.473"); NUMERICOID 1.2.840.113556.1.4.473 DESC server-side sorting of search results 8.8 SASL MechanismsThe name "SASLMechanism" is bound to a context containing DirContext objects representing SASL authentication mechanisms supported by the server. For example, a directory might support the EXTERNAL SASL mechanism (RFC 2222) which requests that the server make use of security credentials exchanged by a lower layer.Each object in "SASLMechanism" context has the following mandatory and
optional attributes:
All the attribute values are represented by the java.lang.String class. You can, for example, obtain the object representing the EXTERNAL SASL mechanism using the following code: If you then get the attributes of the "saslExternalSchema" DirContext object, you would see:DirContext schema = ctx.getSchema(""); // get schema tree DirContext saslExternalSchema = schema.lookup("SASLMechanism/EXTERNAL"); NAME EXTERNAL 9. ExceptionsWhen building an LDAP provider, you need to translate LDAP error codes (see RFC 2251) into JNDI exceptions. You should use the following table when performing the translation. Furthermore, you should encode as much information as possible about the error into the exception's detailed message, "root cause" exception, resolved and remaining names. Note that resolved name and resolved object should correspond to each other's setting.
10. API MappingThe methods of the JNDI API context interfaces are mapped onto LDAP operations as follows.
Update context's environment properties. If multiple contexts share the same set of environment properties, the provider should take care to only modify the intended context's environment. Changing an environment property might require changes to the existing connection the context is using.
For all environment properties, the new property is recorded even if it does not affect the context. See the Environment Properties section. DirContext.bind
If the provider does not support binding any objects in the directory then it should throw OperationNotSupportedException. Otherwise, if it does support binding objects but does not support the supplied object then it should throw IllegalArgumentException.
DirContext.createSubcontext
If the list of requested attributes is null or contains the special attribute identifier '*' then all the user attributes at the LDAP entry are returned. If operational attributes are required then those attribute identifiers must be present in the list of requested attributes.
Ask for, at a minimum, the javaClassName attributes so that the class name of each entry can be determined. If the class name cannot be determined, return javax.naming.directory.DirContext as the class name. The names which are returned are either relative to the named context or they are LDAP URLs.
The names which are returned are either relative to the named context or they are LDAP URLs. Context.lookupLink
DirContext.rebind
Remove context's environment properties. If multiple contexts share the same set of environment properties, the provider should take care to only modify the intended context's environment. Changing an environment property might require changes to the existing connection the context is using.
Note the effect of the java.naming.ldap.deleteRDN property on the behavior of this method.
If the list of requested attributes is null or contains the special attribute identifier '*' then all the user attributes at the LDAP entry are returned. If operational attributes are required then those attribute identifiers must be present in the list of requested attributes. If objects are requested to be returned, then the Java object-related attributes (RFC 2713) are requested in addition to any requested by the API user. If these attributes are present then they are used to assemble the original objects (see Java Objects). If the object cannot be reconstructed according to RFC 2713 then return a DirContext object representing the LDAP entry. The provider should use the DirectoryManager.getObjectInstance method to satisfy calls to the Binding.getObject method. The names which are returned are either relative to the named context or they are LDAP URLs. The provider may use an LDAP compare operation instead of an LDAP search
when the search filter supplied is suitably constrained:
In the forms of search that accept a string filter as argument, the syntax of the filter follows RFC 2254 with the exception that Unicode characters are also allowed. The use of Unicode characters is preferable to the use of encoded UTF-8 octets. The service provider is responsible for translating the Unicode characters into their corresponding UTF-8 representation for transmission to the server. For example, the Greek letter alpha can be specified in the string filter either as "\u03B1" or as "\\CE\\B1". In the form search(Name, Attributes) and related methods, the Attributes argument is converted into a string filter by creating a conjunctive expression out of its elements. Each attribute value is treated as a literal; therefore '*' and other special characters defined in RFC 2254 that appear in the values of an attribute should be escaped according to the rules in RFC 2254. For example, an attribute value of '*' should be encoded as the string "\\2a". In the form search(Name, String filterExpr, Object[] filterArgs) and its String overloaded method, "{num}" expansion is done in the filter by putting in values from filterArgs. Each "{num}" component may appear in the place of "attr" or "value" in Section 4 from RFC 2254. The objects in filterArgs should be encoded in the following
way:
11. FederationThe LDAP service provider should support federation using strong separation and either or both of junctions or implicit next naming system pointer.
12. SASLThe provider supports SASL mechanisms by means of the Java SASL API. This allows SASL mechanism drivers from different vendors to be used with the LDAP provider, and also allows a SASL mechanism driver to be used with different LDAP providers and even non-LDAP protocol libraries.The Java SASL API depends on the Java Authentication and Authorization Service (JAAS), which provides callback support for SASL mechanisms that need to obtain or supply user/application information directly. 12.1 SASL ConfigurationTo specify that SASL authentication be used, you specify the official IANA-registered names of the SASL mechanisms in the java.naming.security.authentication property. The first SASL mechanism on the list that is both available and satisfies the optionally specified policies is used. That is, properties with the prefix "javax.security.sasl.policy." can be used to control the security characteristics of the selected SASL mechanism.Some SASL mechanisms require the identity of the entity being authenticated. This is known as the authentication ID. Some SASL mechanisms, like DIGEST-MD5, require the use of a password and/or a realm. By default, the provider supplies the value of java.naming.security.principal property as the authentication ID to any SASL mechanism that requires the authentication ID, the value of the java.naming.security.credentials property as the password, and the value of the java.naming.security.sasl.realm property as the realm. To override these defaults, use the java.naming.security.sasl.callback property. SASL mechanisms support the notion of authorization identity or authorization ID, which is the entity to which the server should grant access if the authentication succeeds. If the java.naming.security.sasl.authorizationId property has been set, then its value is used as the authorization ID. Otherwise, the empty string is used as the authorization ID, which directs the server to derive an authorization ID from the client's authentication credentials. See SASL properties for a description of the properties used by an LDAP service provider for supporting SASL. In addition to these properties, there might be properties required for specific SASL mechanisms. For example, a SASL mechanism that supports privacy and integrity needs to know the quality of protection that the client requires. Properties such as these are passed to the SASL mechanism via the environment properties. See the JNDI documentation for how to set environment properties. For example, if the application needs privacy, it can do so by using a call such as: env.put("javax.security.sasl.qop", "auth-conf"); before passing env to the initial context constructor. See the Java SASL API for details about these properties. 12.2 SASL Mechanism DriversThe Java SASL API provides a framework for dynamically plugging in SASL mechanism drivers. The LDAP provider might provide a few default drivers. An application can make additional drivers available to the provider by listing the names of the packages, separated by "|" (vertical bar), in the javax.security.sasl.client.pkgs property. It must then add the drivers' classes to the application's classpath. See the Java SASL API for details.
13. Extensions and ControlsThe provider supports LDAP extensions and controls using the javax.naming.ldap package. In addition, the provider supports LDAP unsolicited notifications (which are transmitted in LDAP extended operation responses) using the services of the javax.naming.event package.Several LDAP extensions and controls are defined by the IETF LDAPEXT working group.
14. Event NotificationThe provider supports event notification using the javax.naming.event package.A JNDI application can register for events that occur in the directory, such as the addition or removal of an entry, or the modification of an entry. Applications can also register for unsolicited notifications.
15. SSLThe provider supports SSL according to the SSL interface specification. SSL is activated by setting the java.naming.security.protocol environment property as follows:env.put(Context.SECURITY_PROTOCOL, "ssl");and by selecting the hostname and port number of an LDAP server that supports SSL. Once an SSL connection has been established subsequent LDAP protocol exchanges take place over that secure connection. If, in addition, LDAP authentication is also required then the java.naming.security.authentication, java.naming.security.principal, and java.naming.security.credentials environment properties should be set, as appropriate. If LDAP authentication is required and the SSL credentials should be reused for LDAP authentication then set the java.naming.security.authentication environment property to select the SASL EXTERNAL mechanism, as follows: env.put(Context.SECURITY_AUTHENTICATION,
"EXTERNAL");
Copyright © 1999-2001 Sun Microsystems, Inc., All Rights Reserved. |