LDAP Schema的概念和基本要素

Schema是LDAP的一个重要组成部分，类似于数据库的模式定义，LDAP的Schema定义了LDAP目录所应遵循的结构和规则，比如一个 objectclass会有哪些属性，这些属性又是什么结构等等，schema给LDAP服务器提供了LDAP目录中类别，属性等信息的识别方式，让这些可以被LDAP服务器识别。
    在LDAP的schema中，有四个重要的元素：
    1. Objectclass
    objectclass定义了一个类别，这个类别会被不同的目录（在LDAP中就是一个Entry）用到，它说明了该目录应该有哪些属性，哪些属性是必须的，哪些又是可选的。一个objectclass的定义包括名称（NAME），说明（DESC），类型（STRUCTURAL或AUXILARY ，表示是结构型的还是辅助型的），必须属性（MUST），可选属性（MAY）等信息。

      在BAP产品中，有下面几种类别

Java代码  

1. # GalaxyTitle    
2. objectclass ( 2.16.840.1.153730.3.4.2  
3.     NAME 'GalaxyTitle'  
4.     DESC 'GalaxyTitle use to manage title'  
5.     SUP top   
6.     STRUCTURAL   
7.         MUST ( uid )   
8.     MAY (   
9.          sortid )   
10.     )     
11.        
12. # GalaxyPost    
13. objectclass ( 2.16.840.1.153730.3.4.32  
14.     NAME 'GalaxyPost'  
15.     DESC 'GalaxyPost use to manage post'  
16.     SUP top   
17.     STRUCTURAL   
18.         MUST ( uid )   
19.     MAY (   
20.          sortid $ type )   
21.     )    
22.   
23. # GalaxyDuty   
24. objectclass ( 2.16.840.1.153730.3.4.22  
25.     NAME 'GalaxyDuty'  
26.     DESC 'GalaxyDuty use to manage duty'  
27.     SUP top   
28.     STRUCTURAL   
29.         MUST ( dutyuid )   
30.     MAY (   
31.          sortid )   
32.     )    
33.   
34.   
35. # GalaxyGroup    
36. objectclass ( 2.16.840.1.153730.3.2.12  
37.     NAME 'GalaxyGroup'  
38.     DESC 'GalaxyGroup use to manage group'  
39.     SUP top   
40.     STRUCTURAL   
41.     MUST ( uid )   
42.     MAY (   
43.         sysid $ employeeids $ sortid $ groupType $ searchCondition $ groupManager $ telephone $   
44.         email $ gfax $ others1 $ others2 $   
45.         others3 $  uniqueMember $ searchConditionXml)   
46.     )     
47.   
48.   
49.   
50. # GalaxyPeople   
51. objectclass ( 2.16.840.1.153730.3.2.22  
52.     NAME 'GalaxyPeople'  
53.     DESC 'GalaxyPeople use to manage people'  
54.     SUP InetOrgPerson   
55.     STRUCTURAL   
56.     MAY (   
57.         otherDepartmentNumber  $ sortid   $  ifactivated  $  peopleLevel $ leadermember $ leaderFilter $ title $ post $ globalsortid $  virtualaccount   
58.         )   
59.     )    
60.          
61.        
62. # GalaxyOrganization    
63. objectclass ( 2.16.840.1.153730.3.2.2  
64.     NAME 'GalaxyOrganization'  
65.     DESC 'GalaxyOrganization use to manage dep'  
66.     SUP top   
67.     STRUCTURAL   
68.         MUST ( uid )   
69.     MAY (   
70.         sysid $ employeeids $ sortid $ depmanager $ telephone $   
71.         email $ gfax $ others1 $ others2 $   
72.         others3 $ depmanagerFilter $ title $ post)   
73.     )     
74.   
75.   
76.        
77. # GalaxyContainer    
78. objectclass ( 2.16.840.1.153730.3.2.16  
79.     NAME 'GalaxyContainer'  
80.     DESC 'a container,can fill with people,org,group...'  
81.     SUP top   
82.     STRUCTURAL   
83.         MUST ( cn )   
84.     )       
85.         
86. # GalaxyLevel    
87. objectclass ( 2.16.840.1.153730.3.3.18  
88.     NAME 'GalaxyLevel'  
89.     DESC 'level inof'  
90.     SUP top   
91.     STRUCTURAL   
92.         MUST ( cn $ number )   
93.     )      
94.        
95.        
96. # GalaxyAttOfPeople    
97. objectclass ( 2.16.840.1.153730.3.3.19  
98.     NAME 'GalaxyAttOfPeople'  
99.     DESC 'att name and sn'  
100.     SUP top   
101.     STRUCTURAL   
102.         MUST ( sn $ cn )   
103.     )        

# GalaxyTitle 
objectclass	( 2.16.840.1.153730.3.4.2
    NAME 'GalaxyTitle'
	DESC 'GalaxyTitle use to manage title'
    SUP top
    STRUCTURAL
        MUST ( uid )
	MAY (
		 sortid )
	)  
	
# GalaxyPost 
objectclass	( 2.16.840.1.153730.3.4.32
    NAME 'GalaxyPost'
	DESC 'GalaxyPost use to manage post'
    SUP top
    STRUCTURAL
        MUST ( uid )
	MAY (
		 sortid $ type )
	) 

# GalaxyDuty
objectclass	( 2.16.840.1.153730.3.4.22
    NAME 'GalaxyDuty'
	DESC 'GalaxyDuty use to manage duty'
    SUP top
    STRUCTURAL
        MUST ( dutyuid )
	MAY (
		 sortid )
	) 


# GalaxyGroup 
objectclass	( 2.16.840.1.153730.3.2.12
    NAME 'GalaxyGroup'
	DESC 'GalaxyGroup use to manage group'
    SUP top
    STRUCTURAL
    MUST ( uid )
	MAY (
		sysid $ employeeids $ sortid $ groupType $ searchCondition $ groupManager $ telephone $
		email $ gfax $ others1 $ others2 $
		others3 $  uniqueMember $ searchConditionXml)
	)  



# GalaxyPeople
objectclass	( 2.16.840.1.153730.3.2.22
    NAME 'GalaxyPeople'
	DESC 'GalaxyPeople use to manage people'
    SUP InetOrgPerson
    STRUCTURAL
	MAY (
		otherDepartmentNumber  $ sortid   $  ifactivated  $  peopleLevel $ leadermember $ leaderFilter $ title $ post $ globalsortid $  virtualaccount
	    )
	) 
	  
	
# GalaxyOrganization 
objectclass	( 2.16.840.1.153730.3.2.2
    NAME 'GalaxyOrganization'
	DESC 'GalaxyOrganization use to manage dep'
    SUP top
    STRUCTURAL
        MUST ( uid )
	MAY (
		sysid $ employeeids $ sortid $ depmanager $ telephone $
		email $ gfax $ others1 $ others2 $
		others3 $ depmanagerFilter $ title $ post)
	)  


	
# GalaxyContainer 
objectclass	( 2.16.840.1.153730.3.2.16
    NAME 'GalaxyContainer'
	DESC 'a container,can fill with people,org,group...'
    SUP top
    STRUCTURAL
        MUST ( cn )
    )    
     
# GalaxyLevel 
objectclass	( 2.16.840.1.153730.3.3.18
    NAME 'GalaxyLevel'
	DESC 'level inof'
    SUP top
    STRUCTURAL
        MUST ( cn $ number )
    )  	
    
    
# GalaxyAttOfPeople 
objectclass	( 2.16.840.1.153730.3.3.19
    NAME 'GalaxyAttOfPeople'
	DESC 'att name and sn'
    SUP top
    STRUCTURAL
        MUST ( sn $ cn )
    )      

  
    2. Attribute
    attribute就是一个上面objectclass中可能包含的属性，对其的定义包括名称，数据类型，单值还是多值以及匹配规则等。后面用具体的例子来说明。
    3. Syntax
    syntax是LDAP中的“语法”，其实就是LDAP中会用到的数据类型和数据约束，这个语法是遵从X.500中数据约束的定义的。其定义需要有一个ID（遵从X.500）以及说明（DESP）
    4. Matching Rules
    是用来指定某属性的匹配规则，实际上就是定义一个特殊的Syntax的别名，让LDAP服务器可以识别，并对定义的属性进行匹配。
    LDAP的schema的主要元素就是这些了，下面列举出了一些LDAP规定好的或是现在比较通用的schema，一般的LDAP服务器都应该可以识别这些定义。
    这就是一个名为subschema的objectclass的定义：
    (2.5.20.1 NAME 'subschema'  AUXILIARY
     MAY ( dITStructureRules $ nameForms $ ditContentRules $
                 objectClasses $ attributeTypes $ matchingRules $ matchingRuleUse ) )
    首先是ID，这里是2.5.20.1，接着是NAME，AUXILIARY说明是辅助型，之后是可选属性的定义，subschema中没有定义必须属性，如果需要定义，应该和MAY一样，将属性放在MUST（）中并用$隔开
  
    再来看一个属性定义：
    ( 2.5.4.3 NAME 'cn' SUP name EQUALITY caseIgnoreMatch )
  可以看到cn属性的父属性是name，它相等性匹配于caseIgnoreMatch（匹配原则为EQUALITY，还有如SUBSTR是字符串匹配，ORDERING是顺序匹配）
  
    syntax定义一般都比较简单，如：
    ( 1.3.6.1.4.1.1466.115.121.1.6  DESC  'String' )
    这个定义说明，这一串数字1.3.6.1.4.1.1466.115.121.1.5就代表了LDAP中的字符串，这个数字串的定义和X.500相关，包括了它的存储方式，所占空间大小等。

    最后看看Matching Rule的例子，前面提到了caseIgnoreMatch，就看他的吧
  ( 2.5.13.2 NAME 'caseIgnoreMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )  
    其实1.3.6.1.4.1.1466.115.121.1.15 就是LDAP数据类型Directory String的ID，说明前面的cn需要等于这个数据类型才有效。
    还有很多常用schema的定义都在了RFC2252中，LDAP服务器都应该支持这些基本的schema。好了，现在基本对LDAP中的schema有个一个大致的说明，可能有不到位或不妥之处，还望大家指正。