转载【RBAC权限模型的运用】

RBAC 是英文（Role-Based Access Control）的缩写

角色访问控制（RBAC）引入了Role的概念,目的是为了隔离User(即动作主体，Subject)与Privilege(权限，表示对Resource的一个操作，即Operation+Resource)。 Role作为一个用户(User)与权限(Privilege)的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给User或Group。Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。例如，对于新闻的删除操作。Role-Privilege是many-to-many的关系，这就是权限的核心。基于角色的访问控制方法（RBAC）的显著的两大特征是：1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

      在一个土建工程管理的项目中，琢磨了一把权限模型。大致的需求就是把用户分为“现场用户”，“总部用户”。总部的用户可以新立项目，查看既有项目的进度与预算的开支；现场的用户负责施工并录入项目进度，填写进度，账务记录。

    在软件系统中，显然不存在总部，现场用户之分。只是同一张用户表带有不同权限的记录而已。下面的数据库模型，有User用户，Role角色，Resource资源三个对象。他们之间关系为多对多，因此另外产生两张连接表。

    Role就是赋予了一组资源的对象，用户通过关联role来获取可以访问的资源，可以将用户与具体的权限分开解耦，而User和Role之间多对多的关系，可以灵活的给一个用户多个role（比如总部经理，还可以兼任现场指挥），而一个role的资源也很方便的付给多个用户。一般系统的权限模型大致如此。

 

本以为设计到这里权限模型就足够了，可是设计下面的Project（项目表）的时候发现了问题。这个项目可能同时数个项目并行，而一个人会不会在不同项目中兼任不同Role呢？比如说张三是项目1中的经理Role，而在项目2中可能只是组长。因此这个特殊的项目权限模型必须加入对Project的关联。

因此，需要在USER_TO_ROLE中间表中，再加入一个Project_ID外键关联到项目表，把用户的角色在这个地方和项目关联起来。同样用户和角色之间有其他制约的关系，只需要在USER_TO_ROLE表中加外键即可，无需影响上面的权限模式

转自：http://blog.csdn.net/d8111/archive/2008/04/30/2348685.aspx

 

相关文章

http://hi.baidu.com/wjj1010/blog/item/28bc18900e0a4788a977a4a9.html

http://hi.baidu.com/wjj1010/blog/item/28bc18900e0a4788a977a4a9.html

http://www.ralasafe.org/zh-hans/%E6%96%87%E6%A1%A3/%E6%9D%83%E9%99%90%E6%A8%A1%E5%9E%8B/

http://www.noahweb.net/mail/2/Project.htm

http://www.noahweb.net/mail/2/Project_1.htm

http://tech.csai.cn/case/no000069.htm

 

这篇是个综合

http://blog.csdn.net/lcj8/archive/2008/12/24/3599579.aspx

JAVA的权限模型

http://blog.sina.com.cn/s/blog_493fd4600100jsc8.html