下载地址 ：http://www.springframework.org/ldap

用Spring LDAP最小需要：

• spring-ldap（spring－ldap包）
• spring－core（用于框架内部的丰富的工具类）
• spring－beans（方便操作java beans的接口和类）
• spring－context（增加通过一致API为应用对象获取资源的能力）
• spring－dao（使经常性的错误处理跟使用中的数据访问分开的异常处理机制）
• commons－logging（简单的日志处理，内部使用）

UserDaoLdapImpl

package cn.com.ldap;
import java.util.List;
import javax.naming.NamingException;
import javax.naming.directory.Attributes;
import org.springframework.ldap.core.AttributesMapper;
import org.springframework.ldap.core.LdapTemplate;
import cn.com.ldap.Preson.Person;
/**
* @author Wangyaodi version 1.0 2008-6-12 | 下午02:55:25
*/
public class UserDaoLdapImpl {
private LdapTemplate ldapTemplate;
public void setLdapTemplate(LdapTemplate ldapTemplate) {
this.ldapTemplate = ldapTemplate;
}
public List getAllPersonNames() {
return ldapTemplate.search("", "(objectclass=person)",
new AttributesMapper() {
public Object mapFromAttributes(Attributes attrs)
throws NamingException {
return attrs.get("cn").get();
}
});
}
}

preson:

package cn.com.ldap;
public class Preson {
public class Person {
private String cn;
private String sn;
public String getCn() {
return cn;
}
public void setCn(String cn) {
this.cn = cn;
}
public String getSn() {
return sn;
}
public void setSn(String sn) {
this.sn = sn;
}
}
}

applicationContext.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<bean id="contextSource"
class="org.springframework.ldap.core.support.LdapContextSource">
<property name="url" value="ldap://192.168.16.XXX:389" />
<property name="base" value="OU=XXX,OU=XXX,OU=XXX,OU=XXX,DC=XXX,DC=XXX,DC=XXX" />
<property name="userName" value="XXX@headquarter" />
<property name="password" value="XXX" />
</bean>
<bean id="ldapTemplate"
class="org.springframework.ldap.core.LdapTemplate">
<constructor-arg ref="contextSource" />
</bean>
<bean id="userDao" class="cn.com.ldap.UserDaoLdapImpl">
<property name="ldapTemplate">
<ref bean="ldapTemplate" />
</property>
</bean>
</beans>

main 

There may have been a time when a single schema was designed to hold everything required for an LDAP implementation (like a relational database schema) but that is no longer true. You will find useful attributes and objectclases scattered all over the place - the power of LDAP arguably comes from the ease of creating and using this apparent anarchy.

The rule is: Every attribute or objectclass (including its superior objectclass or attribute) used in an LDAP implementation must be defined in a schema and that schema must be known to the LDAP server. In OpenLDAP the schemas are made known using the include statement in the slapd.conf configuration file).

The following diagram illustrates the use of schemas as packaging units:

3.3 LDAP objectClasses

An objectClass is a collection of attributes (or an attribute container) and has the following characteristics:

1. An objectclass is defined within a Schema

2. An objectclass may be a part of an objectclass hierarchy in which case it inherits all the properties of its parents, for example, inetOrgPerson is the child of organizationalPerson which is the child of person which is the child of top (the ABSTRACT objectClass which terminates every objectClass hirearchy).

3. An objectclass has a globally unique name or identifier

4. An objectclass, as well as being an attribute container, is also an attribute and may be searched on

5. An objectclass defines its member attributes and whether these MUST (mandatory) be present or MAY (optional) be present in an entry.

6. One or more objectclass(es) must be present in an LDAP entry.

7. Each objectclass supported by a LDAP server forms part of a collection called objectclasses which can be discovered via the subschema.

Defining an objectClass

The formal objectclass definition is defined in RFC 2252 section 4.4 and looks like this:

ObjectClassDescription = "(" whsp

numericoid whsp      ; ObjectClass identifier

[ "NAME" qdescrs ]

[ "DESC" qdstring ]

[ "OBSOLETE" whsp ]

[ "SUP" oids ]       ; Superior ObjectClasses

[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]

; default structural

[ "MUST" oids ]      ; AttributeTypes

[ "MAY" oids ]       ; AttributeTypes

whsp ")"

Ooof! whsp means a space character and when they say it should be there believe them. Rather than try and explain all these entries lets start with some examples.

An objectClass is defined using ASN.1 notation - the following is a simple standard objectclass definition for country taken from the core.schema supplied with OpenLDAP distributions.

objectclass ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL

MUST c

MAY ( searchGuide $ description ) )

Now lets deconstruct this definition:

objectclass is a keyword indicating this is an objectclass definition - see it's not so complicated!

2.5.6.2 NAME 'country' defines a globally unique name for this objectclass and is comprised of two parts: NAME 'country' just allows you to refer to this objectclass by some semi-understandable text - in this case the english word country. The globally unique part is defined by 2.5.6.2 which is called an OID (ObjectIdentifier). The OID 2.5.6.2 was probably the third objectclass ever defined by X.500 (2.5.6 is the joint itu-iso x.500 object classes, the last 2 is a sequence number within that family of OIDs). It does not matter what organization assigns this number but it must be UNIQUE. Obtaining an enterprise OID that allows you to define your own attributes and objectclasses is a trivial and zero cost process via IANA. It is a VERY BAD THING™ to re-use existing OIDs.

SUP 'top' indicates that this objectclass has a PARENT (or SUPerior) objectclass - it is part of a hierarchy. In this case the parent is top which is a special class that terminates (is the highest level) in all objectclasses. An objectclass may have one or more objectclass(es) as Parents.

STRUCTURAL indicates that this objectclass contains data and can form an entry in a DIT. objectClasses may also be ABSTRACT which indicates a non-existent objectclass used for convenience. The most common ABSTRACT objectclass is top which just terminates an objectclass hierarchy. Finally an objectClass may be AUXILIARY which indicates it may be used with any STRUCTURAL objectclass to form an entry but cannot alone form an entry in a DIT.

DESC 'description' OK so we picked a lousy example which does not have a DESC part - but it was short. DESC is an optional value that provides a short text description of the use or contents of the objectclass. It's meant for human beings to read and has no other use. Here is what country could have looked like with a DESC statement included:

objectclass ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL

DESC '2 character iso assigned country code'

MUST c

MAY ( searchGuide $ description ) )

MUST c MUST indicates that the attributes in the following list are mandatory in this case the attribute c has to be present or the entry will fail to load. Single values are written as shown, multiple attributes are enclosed in parentheses and separated with a $ (dollar) sign, such as ( attr1 $ attr2 $ attrn). If there are no mandatory attributes this section is not included.

MAY ( searchGuide $ description ) MAY indicates that the attributes in the following list are optional. Multiple values are written as shown, single attributes do not need the parentheses (see above). If there are no optional attributes this section is not included.

Some more objectClasses

This is how the top objectclass is defined:

objectclass ( 2.5.6.0 NAME 'top' ABSTRACT

MUST objectClass )

Illustrates the use of the ABSTRACT statement in an objectclass. Since top is always the top of a hierarchy - clearly it cannot have a SUP statement. The OID is also assigned by the X.500 standards group.

Many documents insist that the objectclass top is included in LDIF files - it is not always necessary.

This is how the dcObject objectclass is defined:

objectclass ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'

DESC 'RFC2247: domain component object'

SUP top AUXILIARY MUST dc )

Illustrates the use of the AUXILLIARY statement. An AUXILLIARY cannot on its own create an entry. The OID in this example shows the use of a private enterprise OID (ObjectIdentifier). The following fragment shows a fairly typical base DN definition using dcObject:

dn: dc=example,dc=com

dc: example.com

objectclass: dcObject

objectclass: organization

o: Example, Inc.

It is the objectclass: organization that creates the entry. dcObject piggy-backs on this objectclass.

This is how the pilotOrganization objectclass is defined and illustrates that there may be one or more SUPerior (Parent) objectclasses in which the child inherits the properties of ALL its parents (bit like humans really):

objectClasses: ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization'

SUP ( organization $ organizationalUnit ) STRUCTURAL

MAY buildingName )

We have omitted explaining a couple of values (well one actually) - OBSOLETE if it is present it means the objectclass should not be used (duh).

LDAP Attributes

Attributes typically contain data and have the following characteristics:

1. Every attribute is included in one or more objectclass.

2. An objectclass is also an attribute and can be used in searches.

3. To use an attribute in an entry its objectclass must be included in the entry definition and its objectclass must be included in a schema which must be identified to the LDAP server.

4. An attribute's characteristics are defined using ASN.1 notation.

5. An attribute can appear once in any instance of its containing ObjectClass (SINGLE-VALUE) or can apear more than once in any instance of its containing ObjectClass (MULTI-VALUE). MULTI-VALUE is default.

6. An attribute definition may be part of a hierarchy in which case it inherits all the properties of its parents, for example, commonName (cn), givenName (gn), surname (sn) are all children of the name attribute.

7. An attribute definition includes its type, for instance string, number etc., how it behaves in certain conditions, for example are compares case sensitive or case-insensitive and other characteristics (properties).

8. An attribute supported by a LDAP server forms part of a collection called attributetypes which can be interrogated via the subschema.

Defining an Attribute

The formal attribute definition is defined in RFC 2252 section 4.2 and looks like this:

AttributeTypeDescription = "(" whsp

numericoid whsp     ; AttributeType identifier

[ "NAME" qdescrs ]             ; name used in AttributeType

[ "DESC" qdstring ]            ; description

[ "OBSOLETE" whsp ]

[ "SUP" woid ]                 ; derived from this other

; AttributeType

[ "EQUALITY" woid              ; Matching Rule name

[ "ORDERING" woid              ; Matching Rule name

[ "SUBSTR" woid ]              ; Matching Rule name

[ "SYNTAX" whsp noidlen whsp ] ; Syntax OID

[ "SINGLE-VALUE" whsp ]        ; default multi-valued

[ "COLLECTIVE" whsp ]          ; default not collective

[ "NO-USER-MODIFICATION" whsp ]; default user modifiable

[ "USAGE" whsp AttributeUsage ]; default userApplications

whsp ")"

Ouch! whsp means a space character and must be present. Rather than explain each bit of gobbledegook lets again start with some examples.

An attribute is defined using ASN.1 notation - the following is a simple standard attribute definition for commonName (cn) taken from the core.schema supplied with OpenLDAP distributions.

attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' ) SUP name )

Now lets deconstruct this definition:

attributetype indicates this defines an attribute - wow.

2.5.4.3 NAME ('cn' 'commonName') defines a globally unique name for this attribute and is comprised of two parts: NAME ('cn' 'commonName' just allows you to refer to this attribute by some semi-understandable text - in this case either the english word commonName OR the shortform (or alias) cn in principle there are no limits to the number of definitions or aliases you can have as long as they are unique. In this multiple entry form the names are enclosed in parentheses and space separated. Since cn appears first it is called the primary name which is very important when it comes to indexing entries.

The globally unique part is defined by 2.5.4.3 which is called an OID (ObjectIdentifier). The OID 2.5.4.3 was possibly the fourth attribute ever defined by X.500 (2.5.4 is the joint itu-iso x.500 attribute types, the last 3 is a sequence number within that family of OIDs). It does not matter what organization assigns this number but it must be UNIQUE. Obtaining an enterprise OID that allows you to define your own attributes and objectclasses is a trivial process via IANA. It is a VERY BAD THING™ to re-use existing OIDs.

SUP 'name' indicates that this attribute has a PARENT (or SUPerior) attribute - it is part of a hierarchy. In this case the parent is name which we will now look at in detail since, if you recall, the child always inherits the properties of the parent (or SUPerior) attribute (and itself may have additional properties). The SUP entry can use either a 'name' or an OID. The definition SUP 'top' and SUP 2.5.4.41 mean exactly the same - except to the poor reader!

This is the attribute definition of name which is a much more serious definition and the SUPerior (parent) attribute of cn above:

attributetype ( 2.5.4.41 NAME 'name'

EQUALITY caseIgnoreMatch

SUBSTR caseIgnoreSubstringsMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

Now for some more serious deconstruction:

attributetype indicates this defines an attribute - same as before.

2.5.4.41 NAME 'name' defines the globally unique name for this attribute and as before is comprised of two parts: NAME 'name' just allows reference to this attribute by some semi-understandable text and the OID 2.5.4.41 indicates it was defined by the X.500 standards group. The format used, because there is only a single name value, does not need enclosing parentheses as in the commonName example above.

EQUALITY caseIgnoreMatch indicates how this (and any child attributes) will behave when used in a search filter e.g. (cn=jimbob) (cn is a child of name) and no wildcards exist in the search. In this case it defines the match to be case-insensitive. caseIgnoreMatch is a matchingRule and is defined in the subschema.

SUBSTR caseIgnoreSubstringsMatch indicates how this (and any child attributes) will behave when used in a search filter which uses a substring e.g. (cn=jim*) (cn is a child of name) and contains one or more wildcards. In this case it defines that the match is case-insensitive. caseIgnoreSubstringMatch is again a matchingRule and is defined in the subschema.

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} is an OID which defines the data type and what rules (data validation) are applied to the data. The full list is in RFC 2252 section 4.3.2 and in this case the OID defines it to be a Directory String type which is defined in RFC 2252 section 6.10 to be in the UTF-8 form of the ISO 10646 character set. The value {32768} indicates the maximum length of the string and is optional. Some more on LDAP Data Types

Other Characteristics

SINGLE-VALUE Omission of this entry means that it is multi-valued i.e. it can appear more than once in an objectclass or an entry. If the attribute can only accept single values it must be explicitly defined as in the definition of dc below.

attributetype ( 0.9.2342.19200300.100.1.25

NAME ( 'dc' 'domainComponent' )

DESC 'RFC1274/2247: domain component'

EQUALITY caseIgnoreIA5Match

SUBSTR caseIgnoreIA5SubstringsMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 

SINGLE-VALUE )

ORDERING 'matchingrule' is rarely defined and is used to define the collation match - the lexicographic sorting order (allowing searches of <= and >=).

attributetype ( 2.5.4.46 NAME 'dnQualifier'

EQUALITY caseIgnoreMatch

ORDERING caseIgnoreOrderingMatch

SUBSTR caseIgnoreSubstringsMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )

3.5 Matching Rules

Matching rules are part of what is called the operational characteristics of the LDAP server.

matchingRule ( 2.5.13.2 NAME 'caseIgnoreMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

ldapsearch -H ldap://ldap.example.com -x -s base -b "cn=subschema"

"(objectclass=*)" matchingrules

# matchingrules may be changed to 

# attributetypes objectclasses etc., etc.

# Subschema

dn: cn=Subschema

matchingRules: ( 2.5.13.0 NAME 'objectIdentifierMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

matchingRules: ( 2.5.13.1 NAME 'distinguishedNameMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

matchingRules: ( 2.5.13.2 NAME 'caseIgnoreMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

matchingRules: ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

matchingRules: ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

matchingRules: ( 2.5.13.5 NAME 'caseExactMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

matchingRules: ( 2.5.13.6 NAME 'caseExactOrderingMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

matchingRules: ( 2.5.13.7 NAME 'caseExactSubstringsMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

matchingRules: ( 2.5.13.8 NAME 'numericStringMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

matchingRules: ( 2.5.13.10 NAME 'numericStringSubstringsMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

matchingRules: ( 2.5.13.13 NAME 'booleanMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )

matchingRules: ( 2.5.13.14 NAME 'integerMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

matchingRules: ( 2.5.13.15 NAME 'integerOrderingMatch' 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

matchingRules: ( 2.5.13.16 NAME 'bitStringMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )

matchingRules: ( 2.5.13.17 NAME 'octetStringMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

matchingRules: ( 2.5.13.18 NAME 'octetStringOrderingMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

matchingRules: ( 2.5.13.20 NAME 'telephoneNumberMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

matchingRules: ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

matchingRules: ( 2.5.13.23 NAME 'uniqueMemberMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

matchingRules: ( 2.5.13.27 NAME 'generalizedTimeMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

matchingRules: ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

matchingRules: ( 2.5.13.29 NAME 'integerFirstComponentMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

matchingRules: ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

matchingRules: ( 2.5.13.34 NAME 'certificateExactMatch'

SYNTAX 1.2.826.0.1.3344810.7.1 )

matchingRules: ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

matchingRules: ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

matchingRules: ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

matchingRules: ( 1.3.6.1.4.1.4203.1.2.1 NAME 'caseExactIA5SubstringsMatch' 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

matchingRules: ( 1.2.840.113556.1.4.803 NAME 'integerBitAndMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

matchingRules: ( 1.2.840.113556.1.4.804 NAME 'integerBitOrMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

ldapsearch -H ldap://ldap.mydomain.com -x -s base -b "" +

# note the + returns operational attributes

dn:

structuralObjectClass: OpenLDAProotDSE

configContext: cn=config

namingContexts: dc=example,dc=com

namingContexts: dc=example,dc=net

monitorContext: cn=Monitor

supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 (Contentsync RFC 4530)

supportedControl: 2.16.840.1.113730.3.4.18 (ProxiedAuthv2 RFC 4370)

supportedControl: 2.16.840.1.113730.3.4.2 (ManageDSAIT RFC3377)

supportedControl: 1.3.6.1.4.1.4203.1.10.1 (SubEntries RFC3673)

supportedControl: 1.2.840.113556.1.4.319 (pagedResults RFC2696)

supportedControl: 1.2.826.0.1.3344810.2.3 (MatchedValues RFC3876)

supportedControl: 1.3.6.1.1.13.2 (Post Read RFC4527)

supportedControl: 1.3.6.1.1.13.1 (Pre-Read RFC4527))

supportedControl: 1.3.6.1.1.12 (Assertion RFC4528)

supportedExtension: 1.3.6.1.4.1.4203.1.11.1 (ModifyPassword RFC3088)

supportedExtension: 1.3.6.1.4.1.4203.1.11.3 (WhoAmI RFC4532)

supportedExtension: 1.3.6.1.1.8 (Cancel RFC3909)

supportedFeatures: 1.3.6.1.1.14 (Modify-Increment RFC4525)

supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 (OperationalAttrs RFC3674)

supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 (ObjectClassAttrs RFC4529)

supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 (TrueFalse RFC4526)

supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 (LanguageTag RFC3866)

supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 (LanguageRange RFC3866)

supportedLDAPVersion: 3

supportedSASLMechanisms: NTLM

supportedSASLMechanisms: GSSAPI

supportedSASLMechanisms: DIGEST-MD5

supportedSASLMechanisms: CRAM-MD5

entryDN:

subschemaSubentry: cn=Subschema