权限管理中基于角色的访问控制与基于资源的访问控制

　这里只对基于角色的访问控制与基于资源的访问控制做一个思想上的认识

一、说明

   基于角色的权限访问控制RBAC（role-based access control）是以角色为中心进行的访问控制，也就是判断主体subject是那个角色的方式进行权限访问控制，是粗粒度的

　基于资源的权限访问控制RBAC（resource-based access control）是以资源为中心进行的访问控制，只需要为角色添加权限就可以

粗粒度与细粒度

粗粒度权限管理，对资源类型的权限管理。资源类型比如：菜单、url连接、用户添加页面、用户信息、类方法、页面中按钮。。

粗粒度权限管理比如：超级管理员可以访问户添加页面、用户信息等全部页面。

部门管理员可以访问用户信息页面包括 页面中所有按钮。

 

细粒度权限管理，对资源实例的权限管理。资源实例就资源类型的具体化，比如：用户id为001的修改连接，1110班的用户信息、行政部的员工。

细粒度权限管理就是数据级别的权限管理。

细粒度权限管理比如：部门经理只可以访问本部门的员工信息，用户只可以看到自己的菜单，大区经理只能查看本辖区的销售订单。。

二、区别

1、基于角色的访问控制

由于基于角色的权限访问控制的角色与权限往往是多对多的关系（比如admin角色可以所有CURD的权限，部门经理角色有Retrieve权限，这就是多对多关系了），如果角色所对应的权限发生变化 ，那我们所编写的判断逻辑就必须发生改变，可扩展性差

　　　　　　比如：原本只有admin可以访问，那么判断可以这么写

　　　　　　if(role.equals(”admin”)){

　　　　　　　　//retrieve　

　　　　　　}

　　　　　　但是假设后期需要给部门经理角色也赋予retrieve权限，那么必须改变原有代码，或者另外增加代码，总之要改变原有的判断逻辑

　　　　　　if(role.equals("admin") || role.equals("manager")){

　　　　　　　　//retrieve　　　　

　　　　　　}

2、基于资源的访问控制

如果是基于资源的权限访问控制，资源和权限一对一关系比较常见，很多时候资源和权限在数据库中会被合并在一张表中，只需要为资源分配相应的权限。所以一个具体操作对应的权限，只要直接判断用户是否拥有该权限即可，可扩展性强

　　　　　　//判断用户是否具有查看权限，用户的角色可以任意变化，而这条判断语句始终是可行的

　　　　　　if(user.hasPermission("retrieve")){

　　　　　　　　//retrieve　

　　　　　　}

　　　　　　如果用户的权限需要改变，只需要对数据库中用户的角色对应的权限进行改变，而权限与对应资源通常不会有改变的需求

总结：

不过使用基于资源的方式，仍然是需要角色的，用户的权限分配的依据往往是角色（比如：如果我给你admin角色，那么同时也会给你curd的权限）。而进行访问控制时，则不依赖角色（比如：你想查看 ，那么我可以直接问你你有retrieve权限吗？如果有，你就可以访问。而不关心你是什么角色）。