LDAP读书笔记7-模式设计

本文原创作品，如需转载请注明来源，作者：姜涛， [e-mail]

 

模式(schema)设计

如果你有使用数据库的背景的话，你应该已经对模式比较熟悉。简单的说，模式就是决定数据存储在数据库或者是目录中的存储规则。模式非常重要，它帮助管理数据的完整性和质量。同时，模式能够减少数据的重复、提供良好的格式以及给外部程序访问和修改数据提供一个预先定义好的规则。

 

LDAP模式的元素：属性类型、属性语法、匹配规则、对象类(object classes)

 

 

1、属性

1.1、属性名
属性名有如下的属性：
1、大小写无关
2、属性名可以只限使用ASCII字母，数字，连接字符(-,不是下划线)；并且以字母开头
3、在整个目录服务中，名字应该是唯一的
合法命名：cn, telephoneNumber, postalAddress, one-way, faxPhone2, and pagesPerMinute
非法命名：last#, 2for2, my.boss, and favorite_drink

 

一些标准的属性因为历史的原因，用长的或短的名字命名都是可以的，如（commonName和cn），但是大多数情况下，短的名字用的更多，在NDS里面，长的名字有时候会用来做短名字的别名和同义词。

 

1.2、唯一标示属性的OID

OID是一组用点分隔的数字，如2.5.4.16，因为在X.500系统里面是用这种方式来标示属性类型的。虽然OID能代替属性名，但是实际上还是用名字更多一些，因为更容易使用。

 

1.3、文本描述

1.4、 一个属性类型的例子
The description Attribute
( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
翻译一下就是，这个属性名叫description，是一个字符串，能容纳1024个字符，使用caseIgnore系列比较规则，因此在比较的时候，字母的大小写、开头和结尾的空格都将被忽略，OID是2.5.4.13

1.5、 属性等级
在一些LDAP的实现中，很明显的跟最近的X.500标准一样，支持属性的subtype

 

name(SuperType)
|
------------------------------------
|   |    |                 |            |  |
cn sn givenName initials   c  o (subtype)

在上面的例子里面，因为cn、sn是name的subtype，所以当一个查询条件要查询所有name的值的时候，将会把name和它下面的cn、sn等都返回。
属性等级是一个有趣的但是却潜在者造成困苦的功能。大部分的LDAP实现并不支持。

 

1.6、使用指示（标示是给应用程序还是给目录服务用的）

1.7、标示属性值是否可以有重复的值

一个属性可能存储多个值，可以通过multivalued来选择，一般来说multivalued是一个缺省选项，因为大多数属性类型都是多值的。

1.8、标示能否被适当的程序修改

1.9、约束属性值的大小

2、相关联的属性语法

语法也有一个OID，标准语法如下：

 

Table 8.2. Standard Syntaxes

Syntax

OID

Description

Binary	1.3.6.1.4.1.1466.115.121.1.5	按照Basic Encoding Rules (BER) 或者Distinguished Encoding Rules (DER)—for example, an X.509v3 certificate编码
Boolean	1.3.6.1.4.1.1466.115.121.1.7	TRUE or FALSE
CountryString	1.3.6.1.4.1.1466.115.121.1.11	两位国家代码, 如US
DirectoryString	1.3.6.1.4.1.1466.115.121.1.15	按照UTF8存储的文本
DN	1.3.6.1.4.1.1466.115.121.1.12	Distinguished name (pointer to another entry) in string (RFC 2253) format
GeneralizedTime	1.3.6.1.4.1.1466.115.121.1.24	按照X.208格式的日期和时间—for example, 20010911134600Z
IA5String	1.3.6.1.4.1.1466.115.121.1.26	ASCII文本字符串
INTEGER	1.3.6.1.4.1.1466.115.121.1.27	整数值
OctetString	1.3.6.1.4.1.1466.115.121.1.40	8进制
PostalAddress	1.3.6.1.4.1.1466.115.121.1.41	多行的邮寄地址用$分行
PrintableString	1.3.6.1.4.1.1466.115.121.1.44	可打印字符
TelephoneNumber	1.3.6.1.4.1.1466.115.121.1.50	电话号码，按照E.123格式 format—for example, [phone]
URI	1.3.6.1.4.1.4401.1.1.1	Uniform Resource Identifier—for example, a Uniform Resource Locator (URL)

 

 

3、管理比较和搜索的匹配规则

 

标准匹配规则

Matching Rule

Description

booleanMatch	布尔值比较，只有等于被支持
caseIgnoreMatch	大小写忽略，开头和结尾的空格被忽略
caseExactMatch	大小写敏感，开头和结尾的空格被忽略
distinguishedNameMatch	DN比较规则（RDN应该相同，并且类型和值必须匹配）
integerMatch	整数比较
octetStringMatch	二进制比较，一个字节一个字节的比较
telephoneNumberMatch	跟 caseIgnoreMatch类似 , 在比较时，连接符（-）和空格都忽略

 

4、object classes

写到这里，实际上我们可以对比一下关系型数据库，前面关于属性的东西可以理解是字段，而现在要提到的object classes类似于表了。只不过在DS里面，属性是全局的，而关系型数据库里面字段是对应表的；在DS里面object classes对属性的要求也比关系型数据库对字段的要求要宽松很多。只是有一个必选和可选的字段要求。比方说person这个object class，cn、sn和objectclass是必须的，而其他的信息则是可选的。

 

object class是有层次的： top->person->organizationalPerson->inetOrgPerson