WebDaemon 角色定义及角色管理.pdfVIP

WebDaemon 角色定义及角色管理 一、RBAC 概览 角色是权限和用户的双向集合。每个用户都可以被授予一定的角色集。用 户进行访问时可以选定部分角色，该用户对系统资源访问的权限就是所选角色 集的权限并集。 在实际应用环境中，角色的层次是多维的。因此角色的定义就很关键和重 要了。从TCL 的实际环境中，我们拟定以此来定义权限角色。 二、WebDaemon 中角色的基本定义 前面提到的关于RBAC 的研究都只是在理论层面，很多定义以及检验规则 在理论上很有价值，但是在实际运用时却很不理想。许多算法不是难以实现， 就是效率太低。我们在设计WebDaemon 的角色定义时，除了参考上面的理论 模型之外，还考虑到了系统的应用背景以及可能产生的角色之间的关系。因 此，我们在这里对如上的理论模型做了很多简化，力争提高系统效率。 2.1 角色基本定义 整个TCL 公司的角色继承关系是一个三维立体结构： l 从机构体系上看，公司分为总部、大区、分公司、经营部等等几个层 次，如下图所示。层与层之间存在继承关系。 惠州总部 华北大区 华东大区 西南大区 … … 北京分公司 天津分公司 包头分公司 北京经营部 承德经营部 大同经营部 l 从部门管理上看，总公司分为若干个事业部，比如彩电事业部、白家电 事业部等等。每层机构都有对应的事业部，不同机构的相同事业部之间 也存在着一定的继承关系。这棵事业部的继承关系树与上面的机构继承 关系树是彼此交叉的。 l 从人员编排上看，每层机构的每个事业部门中还可能有人员的层次关 系，比如经理和职员等等。而且，不同机构以及事业部的相同名字人员 也应该存在某种继承关系。 因此，至少我们可以把整个公司从三个角度来进行划分：机构、部门以及 人员。 由于三个角度彼此交叉，角色继承关系无法用一棵树来简单明了的表达； 另一方面，如果完全用表格的方式来记录所有的角色继承关系，将会导致角色 与角色的关系表（以下简称RRA ）过于庞大，既不方便查找，也不方便管理。 因此，我们按照下面的方式来定义角色。 我们用一个字符串来给每个角色命名，串中包含了相当一部分角色之间的 继承关系。角色名不能表达的继承关系我们使用一个RRA 表来记录。 具体而言，根据公司角色之间三个角度的重要程度，每一个角色名从左到 右可分为三个部分：机构部分、部门部分、人员部分。具体解释如下： l 机构部分：机构内部层次使用“/ ”分隔，公司总部用“/ ”来标识。按 此约定，华北大区用“/hbdq/ ”标识，华北大区北京分公司用 “/hbdq/bjfgs/ ”标识。注意在每层机构最后一定要加一个“/ ”结束。 因此，在机构部分里，每个“/ ”表示一层继承关系。而“/ ”的个数就 表明了它所属机构的级别。 l 部门部分：如果有的话，部门内部层次使用“?”分隔，最后一个部门 层次后面要加一个“?”结束。虽然目前公司并没有复杂到这种程度， 但是我们这样处理显然提供了更好的扩展性。举例来说，按此约定，总 公司的TV 事业部用“/tv? ”标识，总公司TV 事业部下面的彩色TV 事 业部可以用“/tv?colortv? ”标识。 l 人员部分：我们暂时默认人员之间的层次关系只有一级，就是说暂时不 考虑他们之间的继承关系。按此约定，总公司的TV 事业部的经理用 “/tv?mgr ”标识，总公司的TV 事业部的职员用“/tv?user ”标识。 在角色名的三个部分之间，机构部分与部门部分之间无分隔符，部门部分 与人员部分之间以“?”分隔。如果没有部门部分，即某一机构的人员，那么需 要自动加一个“?”。比如华北大区的经理用“/hbdq/?mgr ”标识。角色名允许 没有人