java - 为 JMS 监听器处理 Spring Security 的首选方法是什么？

Question

我有一个有点单一的 Java 应用程序，它围绕我的业务服务层的 Spring @Service beans 构建。通常，我的每个业务服务方法都有 Spring Security 注释(例如 @PreAuthorize)来为该操作执行适当的授权规则。

在主要的 web 应用程序流程中，这工作得很好；每个 Web 请求都隐含地由 session cookie 等处理身份验证。

但是，当涉及到与其他“内部”系统的各种集成点时，我看不出一个明确的解决方案。

例如，我将使用 JMS 队列中的方法，该队列已经在代理中定义了自己的身份验证和授权规则，因此我想隐式地“信任”我收到的消息。然而，就目前情况而言，像这样的足够简单的 Camel 路线:

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

最终抛出一个 AuthenticationCredentialsNotFoundException。

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

对于此类其他事情，我已经在系统的入口点周围应用 AOP 建议(例如，围绕 Quartz Job 的 execute 方法) ，它会注入(inject)一个 PreAuthenticatedAuthenticationToken，但我不确定这是否真的是最好的方法。

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

Answer 1

不幸的是，有最好的方法来做到这一点。这取决于应用程序，根据我的经验，所有解决方案都有效，但有一些缺点。

第一个解决方案是将@PreAuthorize 移至网络级别。这样您就可以在内部随心所欲地自由使用您的服务。我认为这是更简单的解决方案，更容易理解。您想保护您的网络用户吗？为什么不在 web 层中应用安全性。它的问题是 Web 层比业务层更频繁地更改，如果您不仔细开发 Controller 和端点，则更容易留下安全漏洞。对于大多数应用程序，我仍然会采用这种方法，让服务层只处理业务规则而不是安全性(这也是一种业务规则？)。当然，您仍然可以将一些默认的安全逻辑添加到 Controller 组和其他东西中，这样您就不必在任何地方重复自己。

第二种方法是您采用的方法。在您生成的经过身份验证的上下文中运行此类方法。这有点反逻辑——为什么在没有经过身份验证的用户时在经过身份验证的上下文中运行？你不应该这样做，但不幸的是，如果你想获得安全的服务，这是唯一的方法。这种方法不太容易出现安全错误，您可以更轻松地维护安全性。如果您坚持这样做，您可以使用模板模式或创建一些在上下文中运行内容的执行程序类。

我想不出第三种方法:)