UML软件工程组织

 

 

在LDAP中使用角色(Role)和组(Group)来管理用户

2008-07-14 出处:网络
 

LDAP(轻量级目录服务器)越来越被广泛的使用,特别是在管理海量用户信息和管理身份认证信息的时候,LDAP被国内大多数企业所使用,从中国电信,中国移动,新浪,和许多省市政府部门都使用LDAP来管理用户身份的信息。下面重点介绍在LDAP中管理用户的一些概念和技巧。

LDAP服务器使用树状结构来存储和查找用户的信息。这种树状结构比较适合用户身份信息的存储,因为无论在社会还是在企业中,对人的管理是分层的。从地域上的国家、省市到区域,从企业的大部门到小部门,从总经理到小职员,所有的管理都是分层的。“人类的层次划分是社会活动的自然产物”,忘了这句话是谁说的了,但是我们观察自己的周围环境,树状结构的分层无处不在,这也是LDAP为什么在人员管理上这么流行的原因,也是LDAP最初设计的需求。当然,在这里我们不讨论人类社会活动现象,只讨论LDAP技术问题。

LDAP在存储树状结构的数据比关系型数据库有很大的优势。请试图想想在关系数据库中要实现这种树状的数据,需要费一番功夫,并且要定位层次比较深的节点的数据需要经过复杂的查询和转换。但是LDAP这种树状的结构也有一个重要的缺点,就是很难反映出除了结构层次之外的其他关系(例如在同一个组织之下的管理和被管理的关系),而且当组织结构经常发生变化的情况下,树状结构很难满足这种灵活性的要求。有树状结构特点决定,当一个组织变化的时候,这个组织下的所有节点都需要一一变化。

因此,在LDAP中出现了Group(组)和Role(角色)来动态的管理节点之间的关系。例如,建立一个“管理员”的组或角色,然后可以将不同组织结构下的人员放到“管理员”这个逻辑结构下。那么通过“管理员”这个虚拟的组织结构可以将不同物理组织下的人员动态的组合在一起。例如给“管理员”赋予特殊的权力,使他们能够修改本机构中的人员信息。过了一段时间,如果需要将“管理员”这个逻辑组织取消或者改动,只需要在LDAP的单个节点上操作,而实际“管理员”逻辑结构的成员们,不需要作任何的变化,原来是在哪个物理组织,现在也不用变化。这种Group(组)和Role(角色)的出现是增加了节点之间的关联程度。

Group(组)和Role(角色)的功能基本相同,操作起来也很类似。那么Group(组)和Role(角色)到底有什么区别呢?事实上,由于实现方法不同,Group(组)和Role(角色)在某些操作上体现出不同的性能。

Group(组)的实现机制很简单,每个Group本身就是LDAP的一个实体。这个实体有个member的属性。每次将一个成员添加到这个Group中就会在Member属性中添加一条记录(成员的DN)。如果这个Group有200个成员,那么它的member属性中会有200条记录。这种实现方式非常适合下面的操作:1. 列举当前Group下的所有成员。2.将一些成员从当前的Group中删除或添加。因为所有的成员都记录在Group实体的属性里;这种实现方式非常不适合下面的操作:查找某个用户所属的所有Group。这个操作可能要去每个Group中查找信息。

Role(角色)的实现机制就比较复杂了。其实每个LDAP实体本身都有一个“nsrole”的属性。如果某个角色赋予这个用户的话,就会在这个用户的“nsrole”(其实是nsroleDN,这个会在以后解释)的属性中添加一个角色的记录。如果当前用户有10个角色(例如,他又是领导,又是员工,又是管理员,又是教授....),那么在这个用户的"nsrole"属性中会有10条记录(Role的DN)。这种实现方式非常适合下面的操作: 列举当前用户拥有的所有的角色,因为在用户的“nsrole”属性中记录了所有的角色。因此给一个用户授权通常使用角色,这是因为从用户信息中就能很快获得当前用户所有的角色,以及相关的权限。

另外还有一些准则来帮助判断在设计时到底使用Group还是Role。

1 使用Group会很容易将用户从一系列“逻辑组织”中删除或添加。只要是Group的创建者,就有权限修改Group中的member属性。而角色(Role)的信息存在每个用户的“nsroleDN”中,需要特定的权限才能修改这个属性。

2 如果要使用分布式部署(例如使用Chaining的方式),要考虑到角色(Role)是无法跨越服务器的界限

3 如果成员数量巨大(超过20000)个,可以使用动态组的概念(FilterGroup),这个以后再将。

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号