MethodSecurityInterceptor用于多个方法 [英] MethodSecurityInterceptor for multiple methods

查看:81
本文介绍了MethodSecurityInterceptor用于多个方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想使用Spring Security保护我的服务层。如文档中所述,我需要使用 MethodSecurityInterceptor 来检查是否允许方法调用。

I would like to secure my services layer using Spring Security. As explained in the documentation, I need to use a MethodSecurityInterceptor that will check if the method invocation is allowed.

要确定是否允许给定用户进行服务方法调用,影响调用方法所需的角色(使用 MethodSecurityMetadataSource )对我来说是不够的,因为它还取决于传递给方法的参数。正如文档中所建议的,我可以编写一个自定义 AccessDecisionVoter 并通过安全对象访问参数( MethodInvocation case)。

To decide if a service method invocation is allowed for a given user, affecting a required role to the invoked method (using MethodSecurityMetadataSource) is not enough for me since it also depends on the parameters passed to the method. As suggested in the documentation, I can write a custom AccessDecisionVoter and access the arguments though the secured object (MethodInvocation in this case).

但是,我的授权逻辑在方法上是不同的。例如,多个方法之间的参数可能不同,授权逻辑也不同。

But, my authorization logic is different across the methods. For example, the arguments may be different between multiple methods and the authorization logic will also be different.

我看到两个选项:


  • 我可以在 AccessDecisionVoter 中使用条件逻辑来确定要使用的调用方法和授权逻辑,但它似乎是一个丑陋的解决方案。

  • 我可以为每个安全方法定义一个 MethodSecurityInterceptor 。根据Spring文档, MethodSecurityInterceptor 用于保护许多方法,所以它让我觉得还有另一种方法。

  • I can use conditional logic in the AccessDecisionVoter to determine the invoked method and the authorization logic to use, but it seems to be an ugly solution.
  • I can define one MethodSecurityInterceptor per method to secure. According to the Spring documentation, a MethodSecurityInterceptor is used to secure many methods, so it makes me thinking there is another way.

方法调用后的访问决策存在同样的问题(使用 AfterInvocationProvider )。

The same question exists for access decision after method invocation (using AfterInvocationProvider).

有哪些替代方案?

推荐答案

您可以基于Spring @PreAuthorize()构建。

You can implement your own method security annotations based on Spring @PreAuthorize("") construction.

要获取有关方法的额外信息(超出方法参数值)到SpEL评估上下文,您可以实现你自己的MethodSecurityExpressionHandler

To fetch extra information about the method(beyond method argument values) to SpEL evaluation context you can implement your own MethodSecurityExpressionHandler

@Service
public class MySecurityExpressionHandler extends
    DefaultMethodSecurityExpressionHandler {

    @Override
    public StandardEvaluationContext createEvaluationContextInternal(
        Authentication auth, MethodInvocation mi) {

    StandardEvaluationContext evaluationContext = super
            .createEvaluationContextInternal(auth, mi);

    SomeMethodInfoData methodInfoData = mi.getMethod(). ...;

    evaluationContext.setVariable("someData", <value computed based on method info data>);
    }

    return evaluationContext;
} 

并在 global-method-security中注册声明

<security:global-method-security
        pre-post-annotations="enabled">
        <security:expression-handler
            ref="mySecurityExpressionHandler" />
    </security:global-method-security>

现在您可以创建自定义安全注释(如果需要,可以在MySecurityExpressionHandler中创建额外的流程注释数据)

Now you can create custom security annotations(and extra process annotation data in MySecurityExpressionHandler if required)

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@PreAuthorize("#<someData>")
public @interface CustomSecurityAnnotation { ... }

例如你可以创建自定义注释以检查用户角色而不会弄乱字符串:

for example you can create a custom annotation to check user roles without messing with strings:

@MyUserRoleCheck(MyAppRole.Admin)
public void someMethod()

这篇关于MethodSecurityInterceptor用于多个方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆