原文地址:http://www.coin163.com/java/docs/201309/d_2820039104.html
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
图表 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 列表,导致效率低下。
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
图表 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 列表,导致效率低下。