LDAP设计
2012-11-22 09:30
218 查看
如果你有使用数据库的背景的话,你应该已经对模式比较熟悉。简单的说,模式就是决定数据存储 在数据库或者是目录中的存储规则。模式非常重要,它帮助管理数据的完整性和质量。同时,模式能够减少数据的重复、提供良好的格式以及给外部程序访问和修改 数据提供一个预先定义好的规则。
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,标准语法如下:
3、管理比较和搜索的匹配规则
4、object classes
写到这里,实际上我们可以对比一下关系型数据库,前面关于属性的东西可以理解是字段,而现在要提到的object classes类似于表了。只不过在DS里面,属性是全局的,而关系型数据库里面字段是对应表的;在DS里面object classes对属性的要求也比关系型数据库对字段的要求要宽松很多。只是有一个必选和可选的字段要求。比方说person这个object class,cn、sn和objectclass是必须的,而其他的信息则是可选的。
object class是有层次的: top->person->organizationalPerson->inetOrgPerson
*在定义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,标准语法如下:
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, +1 800 555-1212 |
URI | 1.3.6.1.4.1.4401.1.1.1 | Uniform Resource Identifier—for example, a Uniform Resource Locator (URL) |
Matching Rule | Description |
---|---|
booleanMatch | 布尔值比较,只有等于被支持 |
caseIgnoreMatch | 大小写忽略,开头和结尾的空格被忽略 |
caseExactMatch | 大小写敏感,开头和结尾的空格被忽略 |
distinguishedNameMatch | DN比较规则(RDN应该相同,并且类型和值必须匹配) |
integerMatch | 整数比较 |
octetStringMatch | 二进制比较,一个字节一个字节的比较 |
telephoneNumberMatch | 跟 caseIgnoreMatch类似 , 在比较时,连接符(-)和空格都忽略 |
写到这里,实际上我们可以对比一下关系型数据库,前面关于属性的东西可以理解是字段,而现在要提到的object classes类似于表了。只不过在DS里面,属性是全局的,而关系型数据库里面字段是对应表的;在DS里面object classes对属性的要求也比关系型数据库对字段的要求要宽松很多。只是有一个必选和可选的字段要求。比方说person这个object class,cn、sn和objectclass是必须的,而其他的信息则是可选的。
object class是有层次的: top->person->organizationalPerson->inetOrgPerson
*在定义schema时一定不要有多余的空格
相关文章推荐
- 开始做硕士毕业设计了,预计是用EJBCA+LDAP做个CA,然后结合ACEGI框架,弄个系统。发个帖子算是开工仪式了。
- LDAP实例设计
- 毕业设计之LDAP存储X509证书
- 基于LDAP的Web身份认证机制的研究与设计
- smallworld bm 配为ldap授权后授权界面中无法显示设计权限,需要修改config_local_and_ldap.xml配置文件
- LDAP设计
- 基于LDAP 的Web 邮件服务器的设计与实现
- Ext JS 6开发实例(三) :主界面设计
- 架构设计:系统间通信(40)——自己动手设计ESB(1)
- 设计模式学习之路-状态模式
- 20144303 20145239《信息安全系统设计基础》实验一 开发环境的熟悉
- JAVA设计模式之门面模式(外观模式)
- 逻辑数据库设计 - 单纯的树(递归关系数据)(转)
- java设计模式-行为型模式
- App架构设计经验谈:接口”安全机制”的设计
- 设计模式--抽象工厂模式(简要)(九)
- 设计模式(3)
- 网页全屏背景设计
- 设计模式-桥接模式
- 微软Azure学习总结---电商架构深度解析及架构设计