LDAP 协议
文章目录
- 1. 目录
- 2. X.500与ldap区别
- 3. LDAP基本概念
- 3.1 条目（Entry）
- 3.2 属性（Attribute）
- 3.3 属性类型（AttributeType）
- 3.4 对象类（ObjectClass）
- 3.5 模式（Schema）
- 3.6 backend & database
- 4. LDAP 解释：
- 5. LDAP的特点
- 6. LDAP的主要应用场景
- 7. 总结
LDAP是轻量目录访问协议，英文全称是Lightweight Directory Access Protocol
1. 目录
目录是一个为查询、浏览和搜索而优化的专业分布式数据库，它呈树状结构组织数据，就像Linux/Unix系统中的文件目录一样。目录数据库和关系数据库不同，它有优异的读性能，但写性能差，并且没有事务处理、回滚等复杂功能，不适于存储修改频繁的数据。目录服务是由目录数据库和一套访问协议组成的系统。
类似以下的信息适合储存在目录中：
- 企业员工信息，如姓名、电话、邮箱等；
- 公用证书和安全密钥；
- 公司的物理设备信息，如服务器，它的IP地址、存放位置、厂商、购买时间等；
LDAP是基于X.500标准而发展起来的，但是它更加简单，并且可以根据需要定制。与X.500不同，LDAP支持TCP/IP，这对访问Internet是必须的。
2. X.500与ldap区别
X.500实际上不是一个协议，它是由一个协议族组成：X.501模型强调目录服务基本模型和概念；X.509认证框架是如何在X.500中处理目录客户和服务器的认证；X.511 抽象服务定义X.500被要求提供的功能性服务；X.518 分布式操作过程表明如何跨越多台服务器处理目录服务；X.519 协议规范即是X.500协议，包括目录访问协议DAP、目录系统协议DSP、目录操作绑定协议DOP和目录信息Shadowing协议DISP；X.520 选定的属性类型要求是X.500自己使用的属性类型；X.521选定的对象类即为X.500自己使用的对象类；X.525复制是如何在目录服务器之间复制目录内容。
X.500虽然是一个完整的目录服务协议，但在实际应用的过程中，却存在着不少障碍。由于目录访问协议DAP这种应用层协议是严格遵照复杂的ISO七层协议模型制定的，对相关层协议环境要求过多，随着TCP/IP协议体系的普及，更使得这种协议越来越不适应需要。
LDAP协议从1993年批准，产生了LDAP V1版本，随后于1997年发布了第三个版本LDAP V3，它的出现是LDAP协议发展的一个里程碑性标志，它使LDAP协议不仅仅作为X.500的简化版，同时提供了LDAP协议许多自有的特性，使LDAP协议功能更为完备，具有了更大的生命力。
LDAP V3协议也不是一个协议，而是一个协议族。RFC 2251——LDAP V3核心协议，定义了LDAP V3协议的基本模型和基本操作；RFC 2252——定义了LDAP V3中的基本数据模式（Schema）（包括语法、匹配规则、属性类型和对象类）以及标准的系统数据模式；RFC 2253——定义了LDAP V3中的分辨名（DN）表达方式；RFC 2254——定义了LDAP V3中的过滤器的表达方式；RFC 2255——LDAP统一资源地址的格式；RFC 2256——在LDAP V3中使用X.500的Schema列表；RFC 2829——定义了LDAP V3中的认证方式；RFC 2830——定义了如何通过扩展使用TLS服务；RFC 1823——定义了C的LDAP客户端API开发接口；RFC 2847——定义了LDAP数据导入、导出文件接口LDIF。
3. LDAP基本概念
下图为LDAP 目录树
| 属性 | 别名 | 描述 |
|---|---|---|
| Domain Component | DC | 域组件 |
| Organizational Unit | OU | 组织单位 |
| COMMON NAME | CN | 姓名 |
3.1 条目（Entry）
LDAP条目是有关实体的信息的集合。条目（Entry）就是目录管理的对象，他是LDAP中最基本的颗粒，就像字典中的词条，或者是数据库中的记录。通常对LDAP的添加、删除、更改、检索都是以条目为基本对象的。每个条目Entry由三个主要组件组成：可分辨名称(distinguished name，dn)，属性集合和对象类集合(objectclass)。
每一个条目都有一个唯一的标识名（distinguished Name ，DN）。
上图dn：cn=jsmith,ou=People,dc=example,dc=com。DN在语法上是由多个相对的标识名（distinguished Name ，DN）组成的，他们之间由逗号分隔。如果把DN看做对象的全路径，那么RDN就是其中的每一段路径。通过DN的层次型语法结构，可以方便地表示出条目在LDAP树中的位置。有时在不一致引起歧义的情况下，RDN也特指DN中最靠前的一段，即“cn=jsmith”；而剩余的部分称为父标识（Parent DN，PDN），即“ou=People,dc=example,dc=com”。
RDN本身也可以由多个值构成，比如OU=Tech+CN=doubao,dc=shuyun,dc=com中的RDN为OU=Tech+CN=doubao，由2个值OU=Tech和CN=doubao组成，他们之间由加好隔开。
3.2 属性（Attribute）
每个条目都可以有很多属性（Attribute），比如常见的人都有姓名、地址、电话等属性。每个属性都有名称及对应的值，属性值可以有单个、多个，比如你有多个邮箱。
属性不是随便定义的，需要符合一定的规则，而这个规则可以通过schema制定。比如，如果一个entry没有包含在 inetorgperson 这个schema 中的objectClass: inetOrgPerson，那么就不能为它指定employeeNumber属性，因为employeeNumber是在inetOrgPerson中定义的。
LDAP为人员组织机构中常见的对象都设计了属性(比如commonName，surname)。下面有一些常用的别名：
| 属性 | 别名 | 语法 | 描述 | 值(举例) |
|---|---|---|---|---|
| commonName | cn | Directory String | 姓名 | sean |
| surname | sn | Directory String | 姓 | Chow |
| organizationalUnitName | ou | Directory String | 单位（部门）名称 | IT_SECTION |
| organization | o | Directory String | 组织（公司）名称 | example |
| telephoneNumber | Telephone Number | 电话号码 | 110 | |
| objectClass | 内置属性 | organizationalPerson |
3.3 属性类型（AttributeType）
每个属性都有唯一的属性类型（AttributeType），属性类型约定属性值的数据格式和语法类型（Syntax）。比如，属性cellPhone的类型为telephoneNumber，它规定了电话号码是由数字组成的，其中允许插入一些分隔符，如连接符、括号、空格等。
属性类型也约定了属性值是否可以有多少个，多值属性类型也可以使人员信息的组织变得更加灵活并接近现实情况，比如：人员的手机、地址、邮箱等属性都可以有多个值。这样，用ldap组织的信息会比简单的表结构更加理想。
类型也规定了属性查询时的匹配规则、排序顺序、大小写敏感等。
3.4 对象类（ObjectClass）
对象类（ObjectClass）是属性的集合，LDAP预想了很多人员组织机构中常见的对象，并将其封装成对象类。比如人员（person）含有姓（sn）、名（cn）、电话(telephoneNumber)、密码(userPassword)等属性，单位职工(organizationalPerson)是人员(person)的继承类，除了上述属性之外还含有职务（title）、邮政编码（postalCode）、通信地址(postalAddress)等属性。
通过对象类可以方便的定义条目类型。每个条目可以直接继承多个对象类，这样就继承了各种属性。如果2个对象类中有相同的属性，则条目继承后只会保留1个属性。对象类同时也规定了那些属性是基本信息，必须含有：哪些属性是扩展信息，可以含有。
对象类有三种类型：结构类型（Structural）、抽象类型(Abstract)和辅助类型（Auxiliary）。
- 结构类型是最基本的类型，它规定了对象实体的基本属性，每个条目属于且仅属于一个结构型对象类。
- 抽象类型可以是结构类型或其他抽象类型父类，它将对象属性中共性的部分组织在一起，称为其他类的模板，条目不能直接集成抽象型对象类。
- 辅助类型规定了对象实体的扩展属性。虽然每个条目只属于一个结构型对象类，但可以同时属于多个辅助型对象类。
对象类本身是可以相互继承的，所以对象类的根类是top抽象型对象类
如果将其中一支 top–>person–>organizationalPerson–>inetOrgPerson，比如organizationalPerson派生出职工(employee)对象类，那么它可以含有工号(employeeNumber)、工种(employeeType)等属性。注意，对象类继承的时候会把属性是必须(Must)还是可选（May）的特性也一并继承。也就是说person有cn和sn两个Must属性，organizationalPerson和inetOrgPerson由于直接或间接继承了person，也会有这两个Must属性。
| 对象类 | 必要属性(Required) | 可选属性（Optional） | ||
| top | objectClass | 无 | ||
| person | cn | description | seeAlso | telephoneNumber |
| sn | userPassword | |||
| organizationalPerson | 无 | destinationIndicator | facsimileTelephoneNumber | internationalISDNNumber |
| l | ou | physicalDeliveryOfficeName | ||
| postalAddress | postalCode | postOfficeBox | ||
| preferredDeliveryMethod | registeredAddress | st | ||
| street | teletexTerminalIdentifier | telexNumber | ||
| title | x121Address | |||
| inetOrgPerson | 无 | audio | businessCategory | carLicense |
| departmentNumber | displayName | employNumber | ||
| employeeType | givenName | homePhone | ||
| homePostalAddress | initals | jpegPhoto | ||
| labeledURL | manager | |||
| mobile | o | pager | ||
| photo | preferredLanguage | roomNumber | ||
| secretary | uid | userCertificate | ||
| userOKCS12 | userSMIMECertificate | x500UniqueIdentifier | ||
3.5 模式（Schema）
对象类（ObjectClass）、属性类型（AttributeType）、语法（Syntax）分别约定了条目、属性、值。所以这些构成了模式(Schema)——对象类的集合。条目数据在导入时通常需要接受模式检查，它确保了目录中所有的条目数据结构都是一致的。
3.6 backend & database
LDAP的后台进程slapd接收、响应请求，但实际存储数据、获取数据的操作是由backend做的，而数据是存放在database中，所以你可以看到往往你可以看到backend和database指令是一样的值如 bdb 。一个 backend 可以有多个 database instance，但每个 database 的 suffix 和 rootdn 不一样。
4. LDAP 解释：
LDAP是一个轻量级的产品(LightWeight)，是一个Directory(D)，存取的协议(Access Protocol)。
LDAP是一个数据库，但是又不是一个数据库。说他是数据库，因为他是一个数据存储的东西。但是说他不是数据库，是因为他的作用没有数据库这么强大，而是一个目录。
为了理解，给一个例子就是电话簿（黄页）。我们用电话簿的目的是为了查找某个公司的电话，在这个电话簿中附带了一些这个公司的基本信息，比如地址，经营范围，联系方式等。
其实这个例子就是一个LDAP在现实生活中的表现。电话簿的组织结构是一条一条的信息组成，信息按照行业，类比进行了分类。每条记录都分成了若干的区域，其中涵盖了我们要的信息。这就是一个目录。一个树状的结构，每个叶子都是由一条一条的分成若干区域的记录。LDAP就是这么一个东西。
从概念上说，LDAP分成了DN, OU等。OU就是一个树，DN就可以理解为是叶子，叶子还可以有更小的叶子。但是LDAP最大的分层按照IBM的文档是4层。
还是上面这个例子，电话簿由电话公司进行维护，因此写是由他们去写，去组织。写完了，组织好了，就完成了，以后再写，再组织的次数是有限的。而其作用是为了查找。LDAP也是类似，目的不是为了写，当然LDAP也有数据写入的借口，是可以满足录入的要求的，主要是为了查找。如果有人要写有人要读的并发怎么解决？LDAP的用途不是针对这个来设计的，如果你有这样的需求，解决办法就应该是数据库，而不是LDAP。这就是另外一个例子，Access和SQL Server。Access就是一个数据库产品，但是主要用于家庭，功能和性能都比较弱。SQL Server就是一个专业的数据库系统，功能强大。LDAP是一个轻量级的产品，主要目的是为了查，因此在架构和优化主要是针对读，而不是写。但并不是说LDAP不能满足，只是说强项不在这里。
5. LDAP的特点
- LDAP 是一种网络协议而不是数据库，而且LDAP的目录不是关系型的，没有RDBMS那么复杂，
- LDAP不支持数据库的Transaction机制，纯粹的无状态、请求-响应的工作模式。
- LDAP不能存储BLOB，LDAP的读写操作是非对称的，读非常方便，写比较麻烦，
- LDAP支持复杂的查询过滤器(filter)，可以完成很多类似数据库的查询功能。
- LDAP使用树状结构，接近于公司组织结构、文件目录结构、域名结构等我们耳熟能详的东东。 LDAP使用简单、接口标准，并支持SSL访问。
6. LDAP的主要应用场景
- 网络服务：DNS服务
- 统一认证服务：
- Linux PAM (ssh, login, cvs. . . )
- Apache访问控制
- 各种服务登录(ftpd, php based, perl based, python based. . . )
- 个人信息类，如地址簿
- 服务器信息，如帐号管理、邮件服务等
7. 总结
- LDAP作为轻量级目录查询，利用dn的查询效率十分高
- LDAP十分适合管理带有树结构的数据
- LDAP的数据模型（目录设计）十分重要，关乎到数据冗余大小、查询效率等问题。
- LDAP分页查询需要针对结果循环处理，查询效率一般。
- 实际项目开发中LDAP建议只是作为数据同步中心，因为其对于大数据量的查询效率并不是很高，尤其是数据表变动比较频繁的情况，LDAP中指定大量条件进行模糊搜索时，效率很低。
参考：
Spring Boot集成AD域实现统一用户认证
从X.500到LDAP
ldap.com
LDAP服务器的概念和原理简单介绍
LDAP基础概念
LDAP是什么?
Ldap中文网
Spring Boot 整合 LDAP 开发教程