RBAC权限模型的运用

    角色访问控制（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表中加外键即可，无需影响上面的权限模式