在春季安全方面，多少自定义实施是明智的？除非绝对必要，否则它是如何优化的，哪些部分是最优化的，哪些不应该自定义实现？
我想知道这一点，因为我正在考虑实现动态ACL的方法，该ACL授予或撤销单个对象的主体访问权限以及该类型的所有对象甚至任何String标识符。如果我想能够说
@PreAuthorize("hasPermission(#person, details)")
public void getDetailsForPerson(Person person)
以及
@PreAuthorize("hasPermission('package.path.Person', read)")
public void getAllPersons()
以及
@PreAuthorize("hasPermission('Person', read)")
public void getAllPersons()
以及
@PreAuthorize("hasPermission(#id, 'package.path.Person', read)")
public void getOnePerson(int id)
我必须实施PermissionEvaluator。现在我正在使用它，为什么我要使用确切的spring-security ACL数据模型（如Spring Security Reference Appendix A.3中所述）而不是实现我自己的？如果我想允许对对象类型或字符串以及对象实例进行权限评估，我将不得不实现自己的ACLService。
ObjectIdentity查询的内容相同：我必须自己实现这些内容以及我想从@Entity serialVersionUID生成OID以便能够授予访问权限类型权限。
因此，当我想到越来越多的自定义工具时，我想知道，如果我仍然在正确的轨道上。查看the Denksoft blog等教程。我觉得我错过了很多我们以后可能需要的弹簧安全功能。或者只是春天安全是非常强大和复杂的，如果你需要它，但如果你想，你可以自己完成大部分工作，只需使用通用框架将它们整合在一起？
或者我是否因为不坚持测试的实现而创建潜在的安全漏洞？从安全性和软件设计的角度来看，我的想法是否已经存在危险或仍然可以接受，因为我坚持使用spring-security提供的接口？我还没有定制太多给定的实现......
所以......关于我们计划做什么（类型和对象的权限）以及定制弹簧安全性的想法将非常受欢迎。
干杯！
答案 0 :(得分：2)
嗯，似乎没有人想在这里分享他们关于弹簧安全定制的经验，想法或提示，所以我会将其标记为已回答。
简而言之，我们最终做的是定制实现与数据库交互的所有Spring安全接口，以使用我们自己的JPA / Hibernate访问堆栈。这意味着实施
<强>验证：
CustomerDetailsService来处理我们的帐户表RoleHierarchy解析我们自己的层次结构表（1：n与Role的关系，其中m：n为Account）PersistentLoginToken将记住我的令牌保留在我们的数据库对于我们的特殊访问控制列表，它还支持为类型的所有对象设置权限：
MutableAclService，Acl，AccessControlEntry和LookupStrategy来构建ACL PermissionEvaluator支持类类型（作为String）参数所有这些都是相当多的工作，但仍有一些我们的实现缺乏的东西。它值得吗？当然，我们现在有更多的控制，更多的灵活性和新功能。它稳定吗？我们将看到，到目前为止，自定义实现的45个单元测试听起来很多但实际上并非如此。