基于角色的访问控制(RBAC)设计思想

基于角色的访问控制（RBAC）设计思想
基于角色的访问控制设计思想
摘要
分析访问控制的一般设计思路，提出一套基于角色的访问控制的设计思路，并使其成为一个模块加入到系统中使得系统能实现为不同角色的用户提供不同的权限并进行验证等功能。

内容简介
有这么一个案例：国内有一家大型知名医药企业，它们使用了一套企业管理系统，总公司经理用自己的账户登录后能进行查看企业销售报表，审核订单等操作，而区域销售代表用自己的账户登录后能够使用该系统进行客户信息维护、为客户下订单、提取预付款等操作，在公司总部大楼内，财务部会计用自己的账户登录后可以使用帐务结算、工资发放等操作…
在这套系统中，区域销售代表是无权查看企业销售报表，也无权进行审核订单操作的，其他人也类似，整个企业的所有员工在该系统中都各司其职，都无法越权使用超越自己职责范围的操作。

甚至他们各自进入系统所能看到的界
面都不尽相同。

这对该系统来说，它就必须要有一个判断逻辑：主体、行为、对象，也就是说谁能做什么事或者谁不能做什么事。

本文将和你一起讨论该访问控制模块的设计思想，首先将会提供一些模型并加以分析，然后一步步改进，最后得到一个小型但是比较完整的模型。

目的
注意本文所实现的模型并不是完整意义的访问控制系统，它仅仅实现了其中的一小部分，它只解决一些粗粒度的权限，也就是仅仅告诉系统谁能做什么事或者谁不能做什么事。

从程序的角度来讲，它只是以能为上层的访问控制系统提供服务为目标。

相当多细粒度的权限问题因其极其独特而不具通用意义，它们被看作是业务逻辑的一部分。

比如，要求：合同只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览，这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题，在整个权限系统的架构设计之中对其不予过多考虑。

当然，权限系统的架构也必须要能支持这样的控制判断。

或者说，系统提供足够多但不是完全的控制能力。

系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责，它不提供所有关于权限的问题的解决方法，只提供一个基础，并解决那些具有“ 共性” 的( 或者说粗粒度的) 部分。

功能分析
在总公司经理张三审核订单中，总公司经理是一个角色，张三是一个用户，订单是一个资源，审核是对该资源的一个行为。

如果只说审核，这是无意义的，当它结合了一个特定资源的实例（订单）时，可以称为这是一个权限，也就是说，审核订单是一个权限。

对于总公司经理来说，审核订单这一权限是得到许可授权的，当张三得到总公司经理这一角色的任命后，它就得到了审核订单这一权限的许可授权。

当然，张三既然是总公司经理了，总公司经理的权限有一大堆，比如查看销售报表，所以张三还能进行查看销售报表等操作。

当然还有其它几个人也具有总公司经理这一角色，所以他们能进行和张三同样的工作。

于是，对于张三，它通过总公司经理这一角色获得了属于它的一系列权限集（审核订单、查看销售报表等）。

这样就形成一个映射关系：从张三到他的权限的映射关系。