《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等)背后的技术,我们也将会带领你进行学习,所以请继续阅读。
推荐阅读
-
《Spring Security3》第四章第三部分翻译上(配置安全的密码)
-
《Spring Security3》第四章第三部分翻译下(密码加salt)
-
《Spring Security3》第三章第四部分翻译(修改密码)
-
《Spring Security3》第三章第三部分翻译下(Remember me安全吗?)
-
《Spring Security3》第四章第二部分翻译(JdbcDaoImpl的高级配置)
-
《Spring Security3》第三章第二部分翻译(退出功能的实现)
-
《Spring Security3》第三章第三部分翻译上(Remember me功能实现)
-
《Spring Security3》第五章第二部分翻译下(实现授权精确控制的方法——页面级权限)
-
《Spring Security3》第五章第四部分翻译(方法安全的高级知识和小结)
-
《Spring Security3》第六章第三部分翻译(Session的管理和并发)