什么时候应该在我的应用程序中实现Spring Security ACL? [英] When should I implement Spring Security ACL in my application?

问题描述

Spring Security ACL看起来非常强大，并且在您可以坚持使用其数据库实现时很容易实现.但是，当您必须实现自己的Acl和AclService时，它似乎变得更加复杂(例如，参见此(旧)

Spring Security ACL looks very powerful, and easy to implement when you can stick to their database implementation. However it appears to become much more complicated when you have to implement your own Acl and AclService (see for example this (old) very basic tutorial of only ~26 pages) and it seems difficult to find references and examples for it (that tutorial was from 2008).

例如，在我们的应用程序中，用户具有角色并属于部门.大多数时候，他们被允许根据其角色对属于其部门的对象执行某些操作.在所有情况下，部门+角色足以决定是否应授予用户对特定对象的特定操作.

In our application for example, users have roles and belong to departments. Most of the time, they are allowed to perform some operations on objects that belong to their department based on their roles. In all cases, department + role is sufficient to decide whether a user should be granted a specific operation on a specific object.

用户，角色和部门由外部应用程序管理，当用户连接时，我们会从外部应用程序中检索它们(我们正在使用REST服务，但它也可以是LDAP服务器).

Users, roles and departments are managed by an external application from which we retrieve them when the user connects (we are using REST services but it could as well be an LDAP server).

我们想依靠@PreAuthorize('hasPermission(…)')来实现域对象安全性.因此有2种解决方案:

We would like to rely on @PreAuthorize('hasPermission(…)') for implementing domain object security. 2 solutions are thus in sight:

1. 实施一个自定义的PermissionEvaluator，它执行整个检查；或
2. 用自定义AclService实施ACL，该自定义AclService构建ACL正常工作所必需的对象结构.

1. Implement a custom PermissionEvaluator that does the whole checks; or
2. Implement ACL with a custom AclService that builds the object structure necessary for ACL's to work properly.

实现整个AclService似乎比实现PermissionEvaluator更加困难和复杂，但是ACL似乎更标准.

It seems that implementing the whole AclService would be more difficult and more complex than implementing a PermissionEvaluator, but ACL's seem to be more standard.

您应该基于哪个标准来实现另一个?

Based on which criteria should you implement one or the other?

推荐答案

PermissionEvaluator负责表达式评估，以确定用户是否具有给定域对象的权限.另一方面，AclService提供用于检索Acl实例的接口.本着关注点分离的精神，每个组件都针对一个单独的关注点.

The PermissionEvaluator is responsible for expression evaluation to determine whether a user has a permission for a given domain object. On the other hand the AclService provides an interface for retrieval of Acl instances. In the spirit of Separation of concerns each component addresses a separate concern.

如果任何PermissionEvaluator实现需要基于Acl实例执行评估，则应委派给AclService进行检索.其实AclPermissionEvaluator确实做到了.

If any PermissionEvaluator implementation needs to perform evaluation based on Acl instances, it should delegate to AclService to retrieve them. Actually AclPermissionEvaluator does exactly that.

我建议你这样走.将评估与ACL检索分开.如果Spring AclService和Acl的概念对于您的用例而言太复杂或太复杂，则可以引入自己的服务来检索自定义ACL.然后实施PermissionEvaluator，它将委派给您的ACL服务.

I would suggest you to go this way. Separate evaluation from ACL retrieval. If the concept of Spring AclService and Acl is too complicated or complex for your use case, you can introduce your own service to retrieve custom ACL. Then implement PermissionEvaluator that will delegate to your ACL service.

实际上，我必须做类似的事情，因为我需要将ACL存储在NoSQL数据库中，而Spring提供的内容对我来说不起作用.

Actually, I had to do something similar because I needed to store ACLs in NoSQL database and what Spring provides did not work for me.

我想说的就是调整Spring ACL以满足您的需求所需的工作以及实施定制解决方案的工作.如果您的需求可以通过默认的Spring ACL实现来满足，那就去吧.绝对可以节省您实施自定义解决方案的时间.但是，如果无法使Spring ACL适应您的要求或者太困难了，那么实现自定义解决方案会更容易.

I would say that it is all about the effort needed to adjust Spring ACL to meet your requirements and the effort to implement a custom solution. If your requirements can be satisfied with the default Spring ACL implementation, go for it. It will definitely save you time to implement your custom solution. However, if it is not possible to adapt Spring ACL to your requirements or it would be too difficult, then it can be easier to implement your custom solution.

这篇关于什么时候应该在我的应用程序中实现Spring Security ACL?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！