权限系统机制

ＡＣＬ

ACL介绍

       ACL全称Access Control List，在ACL中，包含用户(User)、资源(Resource)、资源操作(Operation)三个关键要素。通过将资源以及资源操作授权给用户而使用户获取对资源进行操作的权限，模型如下图所示：

图表 1 ACL模型

实现方案

       通过上面对ACL模型的介绍，可以看出ACL是个简单的模型，但其并未提出对于权限的继承、权限的排斥和包含的解决方案。

       ACL模型得到接受必然也是有它的理由的，现在来看看基于ACL模型如何来实现授权模型和权限校验部分。

l         授权模型

授权模型遵循ACL模型进行搭建，建立ACL介绍中的模型。

针对授权模型中的几个关键部分进行描述：

n         授权

根据ACL模型，授权动作主要经过以下几个步骤完成：

u       配置系统资源和资源的操作

按照模型维护Resource、Operation实体以及Resource与Operation的关联模型即可实现。

u       授予用户能操作的资源和资源的操作

按照模型维护用户与Resource以及Operation的关联即可实现。

n         权限的继承

在ACL模型中未定义权限的继承，这也是由于在ACL的模型中根本就没有权限继承的点，因为用户本身是不可能继承的。

在很多改良的ACL模型系统中，会通过给组或组织机构授权来完成，这时就出现了权限继承的点了，如组或组织机构的权限继承，那么在ACL模型中如何去实现这个权限继承呢？

为实现给组或组织机构进行授权，此时通常需要对上述ACL模型进行改造方可实现，模型重构如下：

图表 2 重构后的ACL模型

在对组或组织机构进行授权动作时，经过以下步骤来实现权限的继承：

u       维护当前组或组织机构中所有用户的ACL模型

维护当前组或组织机构和Resource、Operation的关联模型。

递规获取当前组或组织机构的父节点的ACL模型，并合并形成新的Resource、Operation关联列表，此时获取该组或组织机构中的用户产生用户和Resource、Operation的关联ACL模型。

u       维护当前组或组织机构中所有下级节点中的所有用户的ACL模型

递规获取当前组或组织机构的子节点，同时合并形成子节点新的Resource、Operation关联列表，之后获取子节点中的用户产生新的Resource、Operation关联列表。

在经过以上的步骤后权限的继承得以实现，在使用过程中同时发现另外一个问题，在更新组或组织机构下的用户时需要同时维护当前组或组织机构的ACL模型，否则会造成不同步的问题。

n         权限的排斥和包含

权限的排斥和包含在ACL模型中同样没有定义，通常的实现方法是定义Operation的自关联，维护时需增加对Operation自关联的维护以及在维护User、Resource、Operation关联时根据Operation的自关联产生其包含权限的ACL列表。

l         资源权限校验

在以上授权模型的基础上，对于操作主体能否对资源进行操作权限的判断通过ACL列表直接判断用户是否具有对资源进行操作的权限即可。

通常在中小型系统的做法是在用户登录时获取构成用户的ACL列表，以提升资源权限校验的效率。

l         数据权限校验

在ACL模型中未明确定义数据权限校验的实现，根据数据权限校验的需求将数据映射为Resource，对数据的操作映射为Operation，这个时候数据权限的授权模型重构为：

图表 3 数据权限的ACL模型

       基于此模型对数据权限的授权和权限校验进行描述：

n         授权

在对数据进行授权时根据模型此时的授权对象主要有User、Group两种，授权时需要通过以下步骤来完成：

u       维护数据本身构成的ACL模型

维护当前数据、操作与Group、User的关联模型。

递规获取当前数据、操作的父节点的Group、User的关联模型，合并组成新的Group、User列表，根据此列表形成对当前数据进行操作的用户列表，此时更新形成UseràResourceàOperation的ACL列表模型。

u       维护数据所有子节点的ACL模型

递规获取数据的所有子节点，同时对合并形成每个子节点的新的Group、User列表，更新子节点的UseràResourceàOperation的ACL列表模型。

在经过以上的步骤后数据权限的继承以及需求得以实现，在使用过程中同时发现另外一个问题，在更新组或组织机构下的用户时需要同时维护当前组或组织机构的ACL模型，否则会造成不同步的问题。

n         权限校验

u       获取操作者权限范围内的全部数据

直接通过UseràResourceàOperation的ACL列表获取所有数据。

u       分页获取操作者权限范围内的数据

直接通过UseràResourceàOperation的ACL列表分页(结合数据库的分页技术)获取数据。

优缺点分析

       经过上述实现方案的描述，可以看出基于ACL的实现的优点主要在于：

n         易用和高效的权限校验

在进行资源和数据的权限校验时只需通过通过ACL列表即可实现。

       缺点在于：

n         权限的继承

对权限继承不够支持。

n         复杂和低效的授权方式

在进行资源和数据的授权时非常复杂，特别是在加入权限的继承、排斥和包含后，需要在维护本身ACL列表的同时维护所有子节点的ACL列表，导致效率低下。

RBAC

RBAC 模型作为目前最为广泛接受的权限模型。
NIST （The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）[1] 。RBAC0模型如图1所示。 
 
图表 1 RBAC 0 模型
l          RBAC0 定义了能构成一个RBAC控制系统的最小的元素集合
在 RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、 RBAC2、RBAC3都是先后在RBAC0上的扩展。
l          RBAC1 引入角色间的继承关系
角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。
l          RBAC2 模型中添加了责任分离关系
RBAC2 的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。
l          RBAC3 包含了RBAC1和RBAC2
既提供了角色间的继承关系，又提供了责任分离关系。
建立角色定义表。定出当前系统中角色。
因为有继承的问题，所以角色体现出的是一个树形结构。