java为JMS侦听器处理Spring安全性的首选方法是什么？

Question

我有一个有点单一的Java应用程序，它是围绕我的业务服务层的Spring@Servicebean构建的。通常，我的每个业务服务方法都有Spring安全注释（例如@PreAuthorize），以强制执行该操作的适当授权规则

在主要的web应用程序流中，这非常有效；每个web请求隐式地具有由会话cookie等处理的身份验证

然而，当涉及到与其他“内部”系统的各种集成点时，我并不清楚解决方案

例如，我将使用JMS队列中的方法，该队列已经有了自己的身份验证&；代理中定义的授权规则，因此我希望隐式地“信任”我获得的消息。然而，就目前情况而言，一条非常简单的骆驼路线如下：

WidgetService widgetService = lookup(WidgetService.class);
from("activemq:newWidget")
    .unmarshall(...)
    .bean(widgetService, "newWidget");

最后抛出一个AuthenticationCredentialsNotFoundException

这告诉我Camel正确地调用了我的bean，从Spring开始应用了所有神奇的AOP

对于这种类型的其他东西，我已经求助于在系统的入口点周围应用AOP建议（例如，在Quartz Job的execute方法周围），它注入了PreAuthenticatedAuthenticationToken，但我不确定这是否真的是最好的方法

我应该继续将这些“受信任”的入口点包装在通知中以添加身份验证上下文，还是应该将我的服务层更改为具有某些不需要身份验证的业务方法的特殊形式，并确保清楚地记录它们不用于web@Controller方法等

Answer 1

不幸的是，这是最好的办法。这取决于应用程序，根据我的经验，所有解决方案都可以工作，但也有一些缺点

第一个解决方案是将@PreAuthorize升级到web级别。这样，您就可以自由地在内部任意使用您的服务。我认为这是一个更简单、更容易理解的解决方案。您想保护您的web用户，对吗？为什么不在web层中应用安全性呢。它的问题是，web层的变化比业务层更频繁，如果不仔细开发控制器和端点，就更容易造成安全漏洞。我仍然会对大多数应用程序采用这种方法，让服务层只考虑业务规则，而不考虑安全性（这也是一种业务规则？）。当然，您仍然可以向控制器组等添加一些默认安全逻辑，这样您就不必到处重复

第二种方法是您已经采取的方法。在生成的经过身份验证的上下文中运行这些方法。这是一个位计数器逻辑——当没有经过身份验证的用户时，为什么要在经过身份验证的上下文中运行？您不应该这样做，但不幸的是，如果您希望获得安全的服务，这是唯一的方法。这种方法不太容易出现安全错误，并且您可以更轻松地维护安全性。如果您坚持这样做，您可以使用模板模式或创建一些在上下文中运行内容的executor类

我想不出第三种方法：）