基于角色的访问控制”和 基于资源的访问控制

基于角色的访问控制（RBAC）是实施面向企业安全策略的一种有效的访问控制方式。

RBAC（Role-Based Access Control）

基本思想

建立一个角色集合

其基本思想是，对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。这样做的好处是，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，这样将简化用户的权限管理，减少系统的开销。

角色
角色代表了操作集合，可以理解为权限的集合，一般情况下我们会赋予用户角色而不是权限，即这样用户可以拥有一组权限，赋予权限时比较方便。典型的如：项目经理、技术总监、CTO、开发工程师等都是角色，不同的角色拥有一组不同的权限。

隐式角色：
即直接通过角色来验证用户有没有操作权限，如在应用中 CTO、技术总监、开发工程师可以使用打印机，假设某天不允许开发工程师使用打印机，此时需要从应用中删除相应代码；再如在应用中 CTO、技术总监可以查看用户、查看权限；突然有一天不允许技术总监查看用户、查看权限了，需要在相关代码中把技术总监角色从判断逻辑中删除掉；即粒度是以角色为单位进行访问控制的，粒度较粗；如果进行修改可能造成多处代码修改。

显示角色：
在程序中通过权限控制谁能访问某个资源，角色聚合一组权限集合；这样假设哪个角色不能访问某个资源，只需要从角色代表的权限集合中移除即可；无须修改多处代码；即粒度是以资源/实例为单位的；粒度较细。

 

 拿某个用户来说，假设他是采购员。我们已经查出来他对应账号映射的角色是采购员的角色。他可以进行下单操作

 隐式地基于角色的权限控制:用户可能有多个角色
Llist<User> user=Ream.getUser("zhangsan");
for(User u:user){
     if("purchase".equalse(user.getRole())){
       //开放前端下单功能展示
     }

}

 

上面这种访问方式局限性太小了，而且当需要扩展的时候，需要修改源码添加对应角色，如某一天，采购经理也可以下单了。

需要在源码添加采购经理角色，前台下单功能才能展示出来，如果后续100个呢？维护量太大了。

 隐式地基于角色的权限控制:用户可能有多个角色
Llist<User> user=Ream.getUser("zhangsan");
for(User u:user){
     if("purchase".equalse(u.getRole())||"purchaseManager".equals(u.getRole()){
       //开放前端下单功能展示
     }

}

 

上述方式太过于维护太麻烦了。老是要修改源码，理想状态下。我们只需要在前端操作一下就完成了权限的分配了。所以用下面的方式去访问。

基于资源的访问控制（显示角色）基于资源的访问控制

[users]
zhang=123,role1,role2
wang=123,role1
[roles]
role1=user:create,user:update
role2=user:create,user:delete 

规则：“用户名=密码，角色 1，角色 2”“角色=权限 1，权限 2”，即首先根据用户名找到角色，然后根据角色再找到权限；即角色是权限集合；

如wang 拥有role1的角色权限集合即：wang能够create和update

但是现实中，某个用户不能看某些功能，可以看某些功能，但是没拥有某功能的所有操作（如，我可以查看该功能的报表的信息，但是。我不能增删改）我的想法是下面这个

如：系统角色（admin）绑定功能(树形功能模块对应不同子功能的勾选)，用户绑定角色，决定用户使用那些模块功能，
同时映射对应具体功能的权限（如增删查改的操作）