《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等）背后的技术，我们也将会带领你进行学习，所以请继续阅读。