《Spring Security3》第七章第三部分翻译（ACL的注意事项）

 

典型ACL部署所要考虑的事情

         实际部署Spring ACL到业务应用是很复杂的。我们总结了Spring ACL要注意的事情，它们在大多数Spring ACL实现场景中都存在。

关于ACL的伸缩性和性能模型

         对于小型和中型应用，添加ACL功能是很容易的，尽管它增加数据库存储和影响运行时性能，这个影响可能不会那么明显。但是，取决于ACL和ACE建模的粒度，在中到大型应用中，数据库的行数可能会非常惊人，甚至对对熟练的DBA都是很难的任务。

         让我们假设我们将要扩展ACL以覆盖JBCP Pets应用大多数的功能，包括用户账号和订单，还包括JBCP Pets中顾客论坛的帖子。我们对着数据建模如下：

l  所有的顾客都有账号；

l  10%的顾客拥有订单。其中每个顾客的平均订单数是2；

l 订单对顾客是要保护的（read-only），但是管理员也能访问（read/write）；

l  10%的顾客会在顾客论坛上发帖，其中每个顾客的帖子数量是20；

l  帖子对顾客是要进行保护的（read-write），对管理员也是如此。帖子对其它顾客是read-only的。

基于我们对ACL系统的了解，我们知道数据库表有以下的可伸缩相关属性：

表	是否随数据伸缩	可伸缩性注释
ACL_CLASS	NO	每个域类需要一行
ACL_SID	Yes（User）	每个角色（GrantedAuthority）需要一行 每个用户账号需要一行（如果域对象根据用户保护）
ACL_OBJECT_IDENTITY	Yes（域类*每个类的实例数）	每个保护的域对象需要一行
ACL_ENTRY	Yes（域对象实例*单个的ACE条目）	每个ACE需要一行，对于每个域对象可能要多行

         我们可以看到ACL_CLASS并没有伸缩性的考虑（大多数的系统少于1000个域类）。ACL_SID是基于系统中的用户数线性伸缩的。这可能不用考虑，因为其它用户相关的表也以这种方式处理伸缩性（如用户账号等）。

         要考虑的两个表是ACL_OBJECT_IDENTITY和ACL_ENTRY。如果对一个用户有一个订单这种情况计算需要的行数，我的得到如下的估算结果：

        

表	每个订单的ACL数据	每个论坛帖子的ACL数据
ACL_OBJECT_IDENTITY	每个订单需要一行数据	每个帖子需要一行数据
ACL_ENTRY	三行——一行用于拥有者（即顾客的SID）的read访问，两行（一行用于读访问，一行用于写访问）用于管理员组的SID。	四行——一行用于顾客组SID的读访问，一行用于拥有者的写访问，两行用于管理员组（如同订单）

         我们可以使用以上的假设并计算出ACL的伸缩性矩阵：

 

表/对象	伸缩性因素	估算（低）	估算（高）
用户（Users）		10,000	1,000,000
订单（Orders）	# Users * 0.1 * 2	2,000	200,000
论坛帖子（ForumPosts）	# Users * 0.1 * 20	20,000	2,000,000
ACL_SID	# Users	10,000	1,000,000
ACL_OBJECT_IDENTITY	# Orders + # Posts	22,000	2,200,000
ACL_ENTRY	(# Orders * 3) + (# Posts * 4)	86,000	8,600,000

         在典型的ACL实现中，这些预测只是要关联和保护对象的子集，你可以看到存储ACL数据的数据库行数是随着业务数据线性（或更快）增长的。特别是对于大型系统的规划，预测你可能用到的ACL数据特别重要。对于非常复杂的系统拥有数亿行关于ACL存储的数据并不罕见。

不要忽视自定义开发的成本

         使用Spring ACL的安全环境通常需要明显的开发工作以及我们讲过的配置步骤。我们例子的配置场景有以下的限制，这可能会影响到将ACL安全应用到完整站点上：

l  SID和访问凭证硬编码在应用启动的时候；

l  没有提供管理域对象（创建和删除）或管理用户、组的功能；

l  应用没有有效使用ACL的等级体系。

当整个应用规划Spring ACL时，你必须仔细考虑所有域数据管理的地方，并确保这些地方正确更新ACL和ACE规则并失效缓存。一般来说，方法和数据安全发生在应用的服务或业务层，而维护ACL和ACE所需要的钩子（hook）通常发生在数据访问层。

 如果你正在处理一个标准应用的架构，拥有合适的隔离及功能封装，可能会很容易找到一个中央位置标识这些变化。但是，如果你正在处理一个遗留的（或者开始的时候出来没有设计）架构，添加ACL功能并在数据操作的代码中支持钩子（hook）将会很困难。

正如前面所提到的，需要注意的是Spring ACL自从Acegi 1.x时代就没有明显的变化过，大约三年了。在那时，很多用户尝试使用它，并记录和以文档的形式提出了很多限制，它们中的很多保存在Spring Security JIRA库中（http://jira.springframework.org/）。缺陷SEC-479可以作为很多关键限制的入口，它们中的很多在Spring Security3中依然没有处理，（如果它们适用于你的场景）可能会需要很大的自定义编码工作。

以下是一些最重要和常见的缺陷：

l  ACL基础设施需要数字型的主键。对于使用GUID或UUID主键（近来用的越来越多，因为现代数据库提供了高效支持）的应用，这会是很大的限制；

l  JIRA缺陷SEC-1140记录的缺陷，默认ACL实现不能用按位操作正确的对比Permission二进制掩码。在关于许可授权一节，我们已经提到；

l  配置Spring ACL的方法与其它Spring Security功能存在一些不一致。简单来说，在这个功能领域，类代理和属性并没有通过DI（依赖注入）暴露，需要覆盖或重写策略会很耗时且维护代价高昂；

l  Permission的二进制掩码通过整数（integer）实现，所以最多有32个可能的位。比较常见的做法是扩展默认的未分配来声明单个对象属性的权限（例如，为读的员工社会保险号分配一个位）。复杂的部署可能会每个域对象超过32个属性，在这种情况下唯一可选的就是为了这个限制，重新对你的域对象建模。

取决于你特定应用的需要，可能会遇到新的问题，尤其是关于这些实现自定义功能要修改的类。

我应该用Spring Security的ACL吗？

         正如使用整体使用Spring Security是很强的业务依赖，使用Spring ACL也是这样——实际上，这对于ACL可能更明显，因为它紧密连接到业务方法和域对象上了。我们希望这个关于Spring ACL的指导已经为你描述了重要的各层配置和Spring ACL的概念，这用来分析Spring ACL在你的应用中如何使用，并帮助你决定和匹配它的功能到实际应用中。

小结

         在本章中，我们关注访问控制列表安全以及对于这种类型的安全Spring Security ACL模块是如何实现的。我们所做如下：

l  了解访问控制列表的基本概念，以及为什么说它们是授权的有效解决方式；

l  学习Spring ACL实现的关键概念，包括访问控制条目、SID以及对象标识；

l  考察支持ACL系统的数据库模式以及逻辑设计；

l  配置所有需要的Spring Bean来启用Spring ACL模块并增强了一个服务接口来使用注解的方法授权。我们接下来将数据库中已有的用户以及站点使用的业务对象，变成ACE声明和辅助的实例数据；

l  了解Spring ACL许可授权处理相关的概念；

l  扩展了我们关于SpringSecurity JSP标签库和SpEL表达书语言（用于方法安全）的知识来实现ACL检查；

l  讨论易变的ACL概念，并了解在易变的ACL环境中的基本配置和需要自定义的代码；

l  开发了一个自定义的ACL许可授权并配置应用验证器有效性；

l  配置和分析使用Ehcache缓存管理器以减少Spring ACL的数据库影响；

l  分析在复杂业务应用中使用Spring ACL的影响以及设计考虑因素。

 

这完成了本书中关于Spring Security关键概念的部分。在接下来的章节中，我们将会深入讨论Spring Security认证与多种类型的外部系统进行集成。如果你不知道这些系统（OpenID、LDAP等）背后的技术，我们也将会带领你进行学习，所以请继续阅读。