转载：权限设计概要

系统权限设计概述
   因为我在上一个的项目中负责有关权限控制这一块，所以Linkin把权限系统方面的设计工作交给我了。但是，我不想沿用以前我们设计的权限系统，因为我们以前的权限系统有一些缺陷。并且在做以前的权限系统的时候也积累了一些我的想法，希望能在这次的系统中把我以前的一些想法应用上去，设计出一个更好的权限系统，因为这个权限系统是为大中型企业应用框架服务的，所以会比较全面，但是又绝对不会像某些变态的ERP系统对数据表中的每个字段都作CRUD权限控制。我设计的原则是“够用，好用”。权限系统只负责粗粒度上的控制，细粒度的权限控制，交与子业务系统自己负责。

说到权限控制，从应用系统诞生那天起，他就跟随着出现了。说白了所谓权限控制就是你只能访问和操作特定的系统资源。就像正常情况下你只能从银行里取出属于你自己的钱一样。同样你也只能查询你自己的帐户里面的余额。似乎是老生常谈了，那就让我们直奔主题吧。

如何在我们自己的系统中设计一套安全，易用，能够适应以后企业级应用扩展的权限控制机制。经过权衡和我们自己以往的经验，认为基于角色的访问控制方法（RBAC）。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：
   1.减小授权管理的复杂性，降低管理开销。
   2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

首先让我们来认识一下，在角色（Role）控制访问中需要用到的几个概念：
   1.User（用户）。一个具有系统唯一标识（一般是账号Account）的纯粹用户，他和Role和Group有关联。本身他的权限是被分离出去的，User也不能与任何权限有任何的联系。他的权限通过Role去关联。

   2.Role（角色）。角色的作用就是和众多的权限相连，然后一个User或是一个Group必须和一个Role关联，才具有与该Role相连的所有的权限。呵呵不知道，我表达清楚了没有。举一个例子，比如系统中有一个“招聘信息发布员”角色，一个账号“MyAccount”。这个“招聘信息发布员”的角色具有“添加”、“编辑”、“删除”招聘信息的权限。我就只需要把“MyAccount”这个账号加入到“招聘信息发布员”的角色中去，“MyAccount”就具有了相应的权限。如果到后面还有“MyAccount2”“MyAccount3”.也需要同样的权限，和前面一样。我们把他们加入到“招聘信息发布员”角色中去就好了。大大降低了授权管理的复杂度。(在我的想法里，还有一种特殊的Role，这种Role可以和机构有所联系，可以为加入该Role的User指定相应的业务机构，比如“招聘管理员”这个角色，很有可能出现总公司的招聘人员负责几家子公司的招聘工作，那么有了这样的Role,我们那个把招聘人员加入的同时，指定他所管理的机构就可以达到目的。类似的还有一个文秘管理几个公司的情况。这种Role为业务系统的扩展提供了很大的便利。)

   再进一步，我们试着想象如果角色之间可以继承权限，那么权限的设置是不是就更加的简单了呢。角色A只要继承角色B，角色A的权限就是角色A和角色B的权限的合集。这我们这个医疗信息系统中，我决定尝试一下角色可单继承的权限控制。尽可能的简化授权操作。

   3.Group（用户组），似乎这个概念和Role和有雷同之处，感觉都是一些个用户的组合。从本质上说两者确实都是对某些特定用户的抽象和提取。比如说Role（角色）就是对User的操作权限共性的提取。举个例子上面我们提到的“招聘信息发布员”，他理所当然的具有管理本部门招聘信息的权限，这是系统中所有招聘管理员的权限共性。所以就产生了“招聘信息发布员”这个角色。区别于Role,Group提取更多的是User的部门共性和职位共性，Group中的User可以是一个部门中的所有员工，也可以是公司中所有的文秘，甚至可以就是几个人的组合。当然在我们的系统中绝大多数的组都是和机构一一对应的，并且这样的组通过所属机构的层次关系表现出包含关系，子机构的组必然包含于父机构的组。我把这种组称为“Organ Group”——机构组。同时可以添加一些自定义的组,把你想归纳的User加入到该组中，这样的组我把它叫做“User defined Group”——自定义组。 为什么要这么设计呢？把人员划成这么多组。这里有几个优点
    （1）可以简化授权。直接把一个组里面的人员全部加入一个角色，省的一个一个的去加。
    （2）方便的资源管理。在现实的环境中，个个业务部门所属的资源是不一样的。比如一个文件发布的功能，需要选定浏览范围，这样只要把公文赋给几个特定的组就可以了。这几个组里面的人自动获得了浏览该公文的权限。
    （3）业务的灵活体现。因为有自定义组的存在，当出现新的业务，比如有一个临时项目组，需要拉几个人，只需要新建一个自定义组，便可以对其进行各种业务操作。

   4.Permission（权限许可）。在这里先要说说Resource(资源)和 Operation(操作)的概念。Resource就是系统里面可用的功能模块，比如“人员信息管理”。而操作就是在管理模块里的添加，删除和修改等等。Permission就是（Resource + Operation），而Permission就是和Role紧密相连的权限了。Administrator也就是将这些Permission赋给Role，那么Role中的User便具有相应的权限了。

   5.Organ（机构）。这个倒是无需多言。机构是整个信息系统的骨架，最直接的Organ Group就是建立在机构之上的。

   6.Position(职务)。这个概念好像离权限系统的设计有点远，我也一直在犹豫要不要把这个和人事系统更有血缘关系的东东弄到权限系统中来，来回思考了我们框架的目标——“一个高可扩展性，高可靠性，支持快速构建业务的企业级应用基础框架”，并且现在企业数据都希望能够“大集中”、“大统一”，未来的人事系统可以完全的构建在我们的框架之上，作为一个子系统而存在。所以我最终还是决定，将这个概念引到我们的权限系统中来，并且成为不可或缺一部分，任何User必须具有在某个Organ下的Position才能进入到系统。

    Linkin这里指出这样做似乎有过度设计之嫌，不符合XP的精神。我也有这么一点点感觉，因为我感到现在的设计已经基本能解决所有的权限问题了，甚至考虑到了未来的业务系统的权限实现方式。同时，这个权限设计确实有点趋于复杂（当然还不至于变态），会对今后系统管理员的素质提出更高的要求。有点不好把握，还是大家讨论讨论吧。



已发表 2005年9月24日 23:25 作者 windtower