导读：
摘 要 介绍了LDAP轻型目录协议的一些基础知识以及基于LDAP的关于Web应用系统安全性的一种可能的体系结构与实现。
关键词 LDAP, Web认证, 信息安全
1 概述 计算机的世界中，信息能够得到共享，必须要定义各方都支持的标准。X.500标准就是此需求下，于1988年由ITU（international telecommunication union）制定并发布的一个针对标准化分布式目录系统的目录访问协议。然而由于X.500本身十分复杂，规则定的比较死，实现起来不是非常的灵活。于是IETF（internet engineering task force）在X.500的基础上设计了LDAP协议。
LDAP的英文全称是Lightweight Directory Access Protocol，一般简称为LDAP，直译成中文即为轻型目录访问协议。LDAP协议的核心规范由一系列的RFC文件定义。其中在RFC3377中详细说明了轻量目录存取协议第三版(LDAPv3)是由一组九份的 RFC 文件组成。其中包括：
(1)[RFC2251] - 轻量目录存取协议第三版：属于不安全的 LDAP 规格书
(2)[RFC2252] - 轻量目录存取协议第三版：属性语法定义
(3)[RFC2253] - 轻量目录存取协议第三版：以 UTF-8 字符串表达已区分的名称
(4)[RFC2254] - 以字符串表达 LDAP 搜寻过滤器
(5)[RFC2255] - LDAP URL 格式
(6)[RFC2256] - 简介 X.500(96)使用者纲要，为了使用 LDAPv3
(7)[RFC2829] - LDAP 的认证方法
(8)[RFC2830] - 轻量目录存取协议第三版：传输层安全的延伸功能以及RFC 3377 文件本身。
2 LDAP基础知识 LDAP将目录信息以树状结构进行组织。每一个分支称为“条目”（entry）,当然这种分支结构可以进行嵌套，即允许分支再拥有自己的子分支结构。条目本身只是一个名称，用来识别当前分支的名字。所有的信息通过该条目下的属性名（atrribute name）与属性值(attribute value)对的形式存在。
LDAP利用文本文件来存储信息，你可以使用Windows下的记事本或者linux下的vi等文本编辑工具来进行编辑。该文件中的LDAP配置信息和目录条目内容必须按照RFC 2849中所定义的LDIF（LDAP Interchange Format）格式来进行编排。通常在Windows系统下，使用“ldif”作为其文件后缀名。
一个Ldif文件包含：有空行隔开的各个条目（entry）的集合，这些条目通过属性名与属性值对的映射（mapping）来组成，例如图1中的目录结构，可能的LDIF文件内容是：
图1
# LDIF sample
dn: dc=dhu,dc=edu,dc=CN
objectclass: top
objectclass: organization
dn: ou=computerDept,dc=dhu,dc=edu,dc=CN
objectclass: organizationalUnit
ou: computerDept
telephoneNumber: 021- 62378888
description: Container for all teachers and students within the
computerDept.dhu.edu.CNdomain
dn: ou= mathDept ,dc=dhu,dc=edu,dc=CN
objectclass: organizationalUnit
ou: mathDept
在如上示例文件中,所有冒号左边的都是属性名,如dn、objectclass、ou、telephoneNumber和description等，冒号右边的则是与该属性所对应的属性值，第一行以井号开头为注释语句，其后由空行隔开的每一段落为一个条目。
在这里值得注意的是objectclass这个属性。每一个LDAP目录中的条目，都必须有一个objectclass属性，这一属性可以被赋予多个值，但至少要被赋上一个值。每一个条目中的objectclass起着一个模板定义的作用，用来规定、限制该条目中，必须具有其他哪些属性，允许具有哪些属性。也就是说，在一个条目通过objectclass的属性值，来定义哪些个属性是必须在该条目下被描述的，哪些个可选的属性是可描述可不描述的。例如，在上面的示例LDIF文档中的dn: ou=computerDept,dc=dhu,dc=edu,dc=CN条目下，objectclass属性值是organizationalUnit，按照RFC 2256中对于organizationalUnit这一objectclass的定义，该条目必须具有ou这个属性，可以有userPassword、searchGuide、telephoneNumber和 description等21个属性（详细列表可参见RFC 2256）。
3 LDAP的认证机制 LDAP是面向连接，以消息为基础的协议。因此在一个LDAP的目录中必须使用某种认证过程。这一认证进程用来建立客户端的对于每一个对话的权限。所有的查找、对话等操作等必须受到该授权用户所获得的权限等级的控制。
图2显示了另一个对象类person的定义，我们将用到它来进一步讨论LDAP的认证机制。
图2
dn: CN=anfernee wang, ou=computerDept,dc=dhu,dc=edu,dc=cn
objectClass: person
CN: anfernee wang
sn: wang
telephoneNumber:201-1234
userPassword: {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ= =
在这里有一个userPassword的属性。存储了用来验证一个用户的信息。前缀{MD5}表示了其后的信息是通过何种算法来进行加密得出来的。示例中的信息是单词“secret”经过64编码的MD5哈希函数运算得出的。
通过LDAP目录验证的过程成为邦定。大多数用户都习惯使用用户名和密码来登入到一个系统。当一个LDAP客户端要进行验证时，用户名将被特定为某个DN。在这里，用户名就是CN=anfernee wang, ou=computerDept,dc=dhu,dc=edu,dc=cn。用来进行验证的输入数据将与userPassword的属性值进行比较。
LDAP v3 中定义了四种对客户端进行验证的机制:匿名验证、简单验证、基于SSL/TLS的验证、基于SASL的认证。
匿名认证是在绑定操作中使用空的密码。这种认证不需要对用户进行身份确认，使目录内容对所有用户开放数据，比如在对公共电话簿和email地址的查询上，可以使用匿名认证。
简单认证是在绑定操作时，给客户端提交给LDAP服务器一个明文的用户名(DN)/密码对，服务器端与存储着的用户名（DN）/密码对进行对比，如果相符，用户身份认证则成功。这种认证方式由于其密码以明文方式在网络中传输，其安全性比较低。
基于SASL的认证，是将SASL作为一个扩展的认证机制引入到LDAP中。SASL是由RFC2222定义的一个可扩展安全策略，可以作为基于连接的协议（如IMAP和LDAP等）的附加认证机制。SASL允许客户端和服务器在传输任何信任状之前协商安全机制。通过SASL，LDAP可以支持LDAP客户端和服务器端协商的任何类型认证机制，所选择的认证机制取决于所要求的安全水平。一个LDAP客户端可以通过对LDAP服务器的根DES执行一个search操作，获取“supportedSASLMechanisms”属性，就可以知道服务器支持哪些SASL机制。这一属性在访问控制列表ACLs中已经定义为可以以匿名身份读取。
基于SASL的认证包含以下几种SASL机制：使用DIGEST-MD5的SASL认证机制、使用CRAM-MD5的认证机制，使用证书的SASL认证机制和rfc2222种定义的EXTERNAL机制等。
基于SSL/TLS的认证机制。SSL是网景公司设计的主要用于Web安全传输的协议。这种协议在Web上获得广泛的应用。IETF将SSL作了标准化，形成RFC2246文件，并将其成为TLS。从技术上讲，TLS1.0与SSL3.0的差别非常微小。他们的基本流程是这样的：SSL/TLS客户端在TCP链接建立之后，发出一个“Clinethello”来发起握手，这个消息包含了自己可实现的算法列表和其他一些需要的消息，SSL/TLS的服务器端回应一个“Serverhello”，其中确定这次通信使用的是列表中的哪个算法，然后发过去自己的身份和公钥。客户端在收到这个消息后生成一个加密消息，用服务器提供的公钥加密后传过去，服务器端用自己的密钥解密后，会话密钥协商成功，双方可以用同一份会话密钥来通信了。SSL/TLS必须在客户端发送一个绑定请求之前通过发送一个ExtendedRequest来启动一个SSL/TLS会话。SSL/TLS必须在客户端发送一个绑定请求之前通过发送一个ExtendedRequest来启动一个SSL/TLS会话。
4 Web身份验证。 在开发Web应用系统时，安全性的身份验证部分最好是留给Web服务器去处理，这么做有几个原因。一个重要的原因是，Web服务器通常拥有一个解决身份认证问题的经过实践检验的解决方法。如果给安全链增加额外的一个链环，开发人员会因此而提高创建一个弱环的可能性。另一个原因是，它使得大家的应用系统变得更加开放。通常Web服务器与它所依赖的操作系统和安全协议集成得比较紧密。通过让该Web服务器去处理身份认证，大家的应用系统将能有效利用操作系统与Web服务器的这种紧密地集成性。
5 Apache Web服务器的身份验证 假设已经在计算机安装好了Apache Web服务器和Tomcat，而且已配置了Apache，可以正确使用Tomcat作为Apache的servlet和JSP服务器。通过LDAP来对Apache下的用户进行身份认证有许多可获得的免费实现。在http://Modules./网站上可以找到向Apache注册过的模块列表。我们使用较受欢迎的mod_ldap.c模块，该模块以Lyonel Vincent和Norman Richards的工作成果为基础， 目前由Jeff Morrow维护。
Mod_ldap.c源文件必须被编译成一个动态连接库文件mod_ldap.dll，，然后由Apache用它与Ldap数据库进行通讯。该dll文件应该被放在Apache安装的modules目录中。然后给Apache Web服务器的配置文件httpd.conf中添加必要的LDAP配置信息。在其尾部可加入如下信息：
#LDAP Authenticatin Module
LoadModule ldap_module c:/apache/apache/modules/ldap_module.dll
AddModule mod_ldap.c
#We protect /examples
AuthType Basic
AuthName AuthenticationLable
LDAPAuth On
LDAPServer “ldap://localhost:389/”
LDAPBindName uid=initiate,ou=people, dc=dhu,dc=edu,dc=CN
LDAPBindPass initial
LDAPuseridAttr uid
LDAPBase dc=dhu,dc=edu,dc=CN
LDAPSearch Modesubtree
Require Valid-user
一切正常的话，当Web用户访问examples目录下的应用程序时，将首先跳出一个对话框，要求输入用户名和密码来进行验证。验证成功后即可以正常运行examples下的JSP程序了。
6 小结 本文概述了LDAP的一些基本知识，并讨论了LDAP为什么是一个可用来处理安全性与个性化的可行解决方案。LDAP的开放性和分布式特性使得它适合存储分布式应用系统素有使用的不常变数据。
需要指出的是，安全是一个链，它的强度等于它最弱的链环。正确的实现一个LDAP系统并不是一项无足轻重的任务，本文对LDAP的介绍也不足以部署一个完整的基于LDAP的安全系统。但是，本文将给大家提供足够的知识基础，以便大家能使用一个现有的LDAP实现来设计与部署自己的Web Service系统。
参考文献： [1] Gerald Carter . LDAP System Administration , O'Reilly, 2003
[2] M. Wahl T. Howes.Lightweight Directory Access Protocol (v3).RFC2251，1997
[3] 鹿凯宁，周慧勇.目录服务的研究及其上的实现.天津大学， 电子信息工程学院
