针对LDAP的验证方法( 三 )


3.3.认证(Authentication)、证实(Credentials)、身份
标识(Identity)
认证证实是通过一方提供给另一方的证据(evidence),断言提供者一方(例如,一用户)
的身份标识,其试图与另一方(典型为一服务器)建立关联 。认证是产生(generating)、传
递(transmitting)和核实(verifying)这些证实的过程,这样(它们)断言了身份标识 。
认证身份标识是存在于证实中的名字(name) 。
存在许多认证证实的形式——使用的形式依靠于通过双方协商的特定认证机制 。例如:
X.509证书、Kerberostickets、简单身份标识和口令对(passWordpairs) 。注重认证机制
可以强制随着它使用的认证身份标识的形式 。
3.4.授权身份标识(AuthorizationIdentity)
授权身份标识是存取控制因素的一种 。它是用户或者其他实体的名字(name),其请求操
作被执行 。存取控制策略经常表达在授权身份标识术语中;例如,实体X能够在资源Z上执
行操作Y 。
授权身份标识属于一协会(boundtoanassociation),其经常与通过客户提出的认证
身份标识完全地相同,但是它可以是不同的 。SASL答应客户具体指定在客户证实中区别于认
证身份标识的授权身份标识 。这个许可主体(permitsagents)正如使用它们自己的证实认
证的代理服务器(proxyservers),然而(要求)赋予它们的代理[2]请求身份标识的存取特
权(privileges) 。另外,通过像TLS服务提供的认证身份标识的形式可以不相对于应用于明
确的服务存取控制协议的授权身份标识,需要服务特指映射(server-specificmapping)被
做 。从客户提供的认证证实中通过服务组成和生效的授权身份标识的方法是工具相关的
(implementation-specific) 。
4.必须的安全机制
答应任何工具,面对上面的需求,在可以选择的(安全机制)中选择是不策略的
(strategy),很可能导致互操作性问题是很明显的 。在缺少授权(mandates)的情况下,客
户(程序)将被记述(written)不支持任何服务(程序)支持的安全功能(function),或
者更坏,仅仅支持类似明文口令的机制其提供明显不够的(inadequate)安全 。
主动中间攻击(Activeintermediaryattacks)对攻击者的(攻击)执行是很困难的,
同时采用工具防止危害也是很困难的 。在基于熟悉到(perceived)主动中间攻击的危险下去
避免主动中间攻击的危害所付出的代价的情况下,采取方法(Methods)仅仅避免敌对客户
(hostileclient)和被动监听攻击(passiveeavesdroppingattacks)所带来的危害是有
效的(useful) 。
给定已存在的目录,强烈要求看到获得甄别名(DistinguishedName)的形式和能够存
储在目录中的认证数据的身份(标识)机制;这意味着或者这个数据为了虚假的认证是无用
的(就像过去Unix使用的"/etc/passwd"文件格式),或者它的内容从来没有通过无保护的线
路中——也就是说它或者更新(updated)协议的外面(outside)或者仅在会话中更新以很
好地避免了窥探者的危害 。它也希望答应认证方法基于存在的用户身份(标识)形式携带授
权身份标识,目的为了与non-LDAP-based认证服务向后兼容(backwardscompatibility) 。
因此,下列工具的一致性需求(conformancerequirements)如下:
(1)对于只读、公开目录、匿名认证在部分5中描述,能被使用 。
(2)工具提供基于口令(password-based)的认证访问必须(MUST)支持使用
DIGEST-MD5SASL机制[4]的认证,在部分6.1中描述 。这提供了客户避免被动

推荐阅读