Ldap ACL

(1)、控制对什么的访问（What to control access to）<what>
<what>决定了将要应用访问控制的条目和属性。条目通常通过两种方式选定：通过DN或者通过过滤器。下面的示例通过DN选择条目： 
to * 
to dn[.<basic-style>]=<regex> 
to dn.<scope-style>=<DN> 
    第一种格式用于选择所有的条目。第二种格式用于选择标准化的DN与所给正则表达式相匹配的条目（第二种格式不会在本文档中深入讨论）。第三种格式用语选择在所请求的DN范围之内的条目。<DN>是一个标识名的字符串表示，如RFC2253中所述。 
    DN范围可以是以下四种之一：base, one, subtree, 或者 children。这里的base只与所给的DN相匹配，one只与父条目是所给DN的条目相匹配，subtree只与根为所给DN的子树下是所有条目相 匹配，而children匹配所有位于DN之下的条目（除了以DN为标识名的条目以外）。 
    比如，如果目录包含以如下方式命名的条目： 
0: o=suffix 
1: cn=Manager,o=suffix 
2: ou=people,o=suffix 
3: uid=kdz,ou=people,o=suffix 
4: cn=addresses,uid=kdz,ou=people,o=suffix 
5: uid=hyc,ou=people,o=suffix 
    那么： 
dn.base="ou=people,o=suffix" 匹配 2; 
dn.one="ou=people,o=suffix" 匹配 3, 和 5; 
dn.subtree="ou=people,o=suffix" 匹配 2, 3, 4, 和 5; 
dn.children="ou=people,o=suffix" 匹配 3, 4, 和 5。 
    条目也可以通过过滤器收集起来： 
to filter=<ldap filter> 
    这里的<ldap filter>是LDAP搜索过滤器的一个字符串表示，如RFC2254所述。比如： 
    to filter=(objectClass=person) 
    注意到条目可以同时通过DN和过滤器来搜集，只需要同时把两者都包含在<what>子句中即可： 
    to dn.one="ou=people,o=suffix" filter=(objectClass=person) 
    条目的属性通过在<what>搜集器中包含用逗号分隔的属性名列表指定： 
attrs=<attribute list> 
    一个属性的具体取值通过单个的属性名和值选取器来指定： 
attrs=<attribute> val[.<style>]=<regex> 
    有两个特殊的的伪属性entry 和 children。要读取（也就是得到）一个条目，必须要有对目标条目的entry属性的读权限。要添加或者删除一个条目，必须要有对目标条目的 entry属性的写权限，并且还必须要有对条目的父条目的children属性的写权限。要重命名一个条目，必须要同时拥有对目标条目的entry属性的 写权限，对原父条目的children属性的写权限，以及对新的父条目的children属性的写权限。本节末尾的完全示例将会把所有这一切将清楚的。 
    最后要说明一点，选取器“*”是一个特殊的条目选取器，用来选取所有的条目。在没有其他的<what>选取器给出的情况下它将被使用。等价于"dn=.*"。 

(2)、赋予Who访问权限（Who to grant access to）<who>
    部分指明了被赋予访问权限的身份。注意，权限被赋予“身份”(实体:entities)而不是“条目”(entries)。下表说明了身份说明选项：
---Specifier---            ---Entities--- 
*                  All, including anonymous and authenticated users 
anonymous              Anonymous (non-authenticated) users 
users                 Authenticated users 
self                  User associated with target entry 
dn[.<basic-style>]=<regex>     Users matching a regular expression 
dn.<scope-style>=<DN>         Users within scope of a DN 

    DN说明选项使用一个正则表达式来匹配当前身份的“规范”DN。
    其他的控制因素也被支持。比如，a <who> can be restricted by an entry listed in a DN-valued attribute in the entry to which the access applies: 
dnattr=<dn-valued attribute name> 
    dnattr用来授权给一个条目，而该条目的DN是在所列的条目的属性当中（比如，可以给一个条目组的拥有者所在的条目授权）。 

    系统还支持其他的控制方式。比如可以通过一个匹配限制客户端的域名：
domain=
    一些因素可能不是在所有的环境下都是正确的。比如，域名因素依赖于域名查询。因为这些很容易spoofed，所以域名因素不可避免。

(3)、赋予的access权限（The access to grant）<access> 
    可以赋予的的类型可以是如下几种：
---Level---      ---Privileges---      ---Description--- 
none        =0            no access 
auth          =x              needed to bind 
compare     =cx              needed to compare 
search         =scx              needed to apply search filters 
read          =rscx              needed to read search results 
write          =wrscx          needed to modify/rename 
    每一个级别隐含了更低的级别。因此，给予某人写一个条目的权限同时给了他读，搜索，比较和认证的权限。但是，也可以使用权限说明来赋予特定的权限。

(4)、访问控制评估（Access Control Evaluation） 
    在评估某个请求者是否具有对一个条目和/或属性的访问权限时，slapd将条目和/或属性与配置文件中的<what>选取器进行比较。对每一 个条目，数据库级的访问控制首先生效，跟着生效的是全局访问控制指令。按照这样的先后顺序，访问控制指令以它们在配置文件中出现的先后次序被检查。 slapd在碰到第一个匹配条目和/或属性的<what>选取器时终止。对应的访问控制指令就是slapd将要用来评估访问控制权限的。 
    接下来，slapd把提出访问的实体与访问控制指令中的<who>选取器依次比较。当它遇到第一个匹配请求实体的<who>选取器是它将停止。这也就决定了实体能够拥有的对条目和/或属性的访问权限。 
    最后，slapd将访问控制指令中的<access>与客户的请求权限相比较。如果它允许大于或等于的访问权限，访问就被批准。否则，访问将被拒绝。 
访 问控制指令的评估顺序使它们在配置文件中的位置变得很重要。如果一个访问控制指令就它所选的条目而言比另一个更具体，那么它应当出现在配置文件的前面。类 似地，如果一个<who>选取器比另一个更具体，它也应该在配置文件的前面出现。下面给出的访问控制示例将会使这一切变得更清晰。 


存取控制示例：
上面描述的存取控制应用是非常强大的。下面的部分显示了它们的一些实用示例。首先，几个简单的例子：
eg1:    access to * by * read
    这个存取控制指令将读权限赋予每一个人。

eg2:
access to *        ( "to *"指的是<what>即控制对什么的访问 )
by self write        ( "self"指的是<who>即赋予谁访问权限 ; "write"指的是<access>即赋予什么权限 )
by anonymous auth
by * read
    该指令允许用户修改自己的条目，允许认证，并且允许所有其他人读取。注意，只有第一个by 语句匹配应用。因此，匿名用户被赋予认证权限，而非读取权限。因此，最后一个语句和“by users read”效果相同(因为上一条已经将匿名用户验证为users，之后不会再有匿名用户了)。

eg3:
    经常需要对不同的保护级别执行不同的受限操作。以下显示了security strength factors (SSF)可以怎样被使用: 
access to * 
       by ssf=128 self write 
       by ssf=64 anonymous auth 
       by ssf=64 users read 
    这条指令允许用户修改他们自己的条目，如果安全保护强度为128或者更高的话；允许匿名用户拥有auth权限，一般用户拥有读权限，如果确定了级别为64 或者更高的安全保护强度的话。如果客户没有确定足够的安全保护强度的话，暗含的by * none字据将会起作用。

eg4:
    下面的例子显示了通过style specifiers 在两个访问指令中通过DN选择条目的用法，其中，访问指令的顺序是很重要的。
access to dn.children="dc=example,dc=com" 
       by * search 
access to dn.children="dc=com" 
       by * read 
    所有用户都拥有对dc=com 子树下的条目的读权限，例外的是，对那些dc=example,dc=com 子树下的条目，用户仅仅有搜索的权限。dc=com 是不可访问的，因为没有访问指令匹配该条DN。如果这里的指令顺序颠倒了的话，那么尾部的指令将永远不会被用到，因为所有 dc=example,dc=com 下的条目也都是dc=com 下的条目。
(可以理解为:下一个"access to"是除去上一个里的内容的,上面的范围要更精确) 
    同时要注意到如果没有与指令相匹配的访问权限或者没有by <who>子句的话，访问将被拒绝。也就是说，每一个access to 指令都是以一个暗含的by * none 子句结尾的，并且每一个访问列表都以一个暗含的access to * by * none指令结尾。 

eg5:
    下面的示例再一次说明了对access指令和by <who>子句而言出现顺序的重要性。它也显示了属性选取器和各种<who>选取器的用法。
access to dn.subtree="dc=example,dc=com" attr=homePhone 
       by self write 
       by dn.children="dc=example,dc=com" search 
       by peername=IP:10\..+ read 
access to dn.subtree="dc=example,dc=com" 
       by self write 
       by dn.children="dc=example,dc=com" search 
       by anonymous auth 
    本例对"dc=example,dc=com"子树中的条目起作用。除了homePhone之外，一个条目可以写它所有的属性，example.com 下的条目可以被它自己搜索，其他任何人都没有权限访问（暗含by * none），例外是经过认证/授权的用户可以（总是匿名进行）。homePhone属性对条目自身而言是可写的，对example.com下的条目是可搜 索的，对来自10网络的客户总是可读的，否则就是不可读的（暗含by * none）。所有其他的访问都将被拒绝，因为暗含有access to * by * none子句。

eg6:
    有时，允许一个特定的DN来从一个属性中增加或者删除自己是很有用的。比如，如果您想创建一个组，并且允许人们向该组的member属性中增加或者删除自己的DN，应该使用如下的存取控制指令来完成这一点：
access to attr=member,entry
       by dnattr=member selfwrite
    这个dnattr说明的选择器说明，该存取控制应用于member属性中列出的条目。selfwrite存取控制选择器说明那些成员只能从属性中增加或者 删除自己，而不能增加或者删除其他值。附加的“entry”是必须的，因为要访问该条目的属性，能够访问该条目是必须的。