Spring Security Kerberos 与基本链接

Posted 2023-02-27

【中文标题】Spring Security Kerberos 与基本链接

【英文标题】：Spring Security Kerberos chained with basic

【发布时间】：2015-08-19 16:07:20

【问题描述】：

我有一个关于 Spring Security 的快速问题。

我正在寻找一种将安全性集成到我们的应用程序中的解决方案，该解决方案提供 SSO，但也提供 HTTP 基本功能。

我们系统的其中一个自动化部分只能支持基本身份验证，而且我们完全被它锁定了。目前，我们的目标是将 Kerberos 用于我们的 SSO 解决方案，然后还支持基本（非常有限的使用）。所有这些都将保护通过 resteasy 运行的 RESTful Web 服务。

在 Spring Security 中将 Kerberos 和 BASIC 链接在一起的这种解决方案中是否有人认为存在任何固有的不可能性？ 我们遇到了 WildFly 的问题，并且 undertow 无法支持使用 HTTP 的多种不同的身份验证方法握手中的响应代码。

感谢您的意见

【参考方案1】：

由于这个问题有点棘手，我假设您已经熟悉Spring Security Kerberos samples，它展示了如何使用表单身份验证作为后备配置 kerberos 身份验证。 我没有证据表明它会起作用，但我认为您应该能够将您的 kerberos 身份验证与基本身份验证链接起来，而不会出现任何问题。我分享我的想法...

思路一：过滤链

支持多种身份验证方法的技巧是正确设置身份验证过滤器的顺序。 如果顺序错误，客户端可能会挂起基本身份验证，并且可能永远无法到达 kerberos 身份验证过滤器，因为会弹出浏览器的基本身份验证对话框。这可能取决于 Spring 中基本身份验证提供程序和过滤器的实现方式。无论如何，如果顺序正确，那么在 kerberos 过滤器（基本身份验证过滤器）之后的链中的下一个过滤器将开始工作。

想法 2：Kerberos 身份验证不应破坏基本身份验证

浏览器应该将与 kerberos 服务提供者的通信与与基本身份验证提供者的通信区别对待，因为协议不同。 SAML 通信在it's own namespace 中运行，因此我认为它不应该影响基于 HTTP 标头中授权元素的基本身份验证通信。

编辑： 即使关于命名空间的假设在浏览器行为中没有任何作用，sequence diagram 中的第 6 步将是一个关键点。当过滤器链接正确时，Spring 应该返回一个 401 响应，如 401 - Access denied - WWW-authenticate - Basic realm = "your domain" 这将强制您的浏览器进入基本身份验证。

思路 3：Spring Security Kerberos 中的 Spnego 协商

Spring Security Kerberos 文档中的Spnego configuration 完全建立在这些想法之上。这也可以在样本中看到，在this WebSecurityConfig.java 的第 49 和 50 行

如果您遇到麻烦，我会感到惊讶。

最后一个想法

如果没有要求强制您进行基本身份验证，我建议不要使用它。最好使用基于令牌的身份验证。即使我不完全同意这个博客的所有细节，它也会解释why basic auth shouldn't be used，如果你可以避免的话。

【参考方案2】：

我强烈建议您阅读 Mika 的回答。它做得很好，给了我前进的信心。

这最终奏效了；但我会解释我遇到的几个症结。

我使用请求匹配器将我的呼叫分成不同的HTTP configuration blocks

在订单 1 中，我配置了一个块以通过用户代理过滤来自特定工具的请求。在该块中，我基本上以标准的 OOTB 方式配置了基本身份验证。不过，我确实编写并提供了自己的身份验证提供程序，该提供程序调用了我们用来通过用户名/密码管理用户的底层系统。

然后，按顺序 2，我配置了一个块来处理 Kerberos。在与 Kerberos 提供程序配置进行角力并提出在我们的底层系统中进行身份验证的方案之后，这一切都处理得很好。从 Kerberos 获取连接到我的 Web 应用程序的域用户的用户名后，我检查了该用户名是否在 my 系统中。如果是，我们将它们登录。如果不是，我们将它们引导到登录页面。 （不是每个域用户都被授权使用我们的网络应用程序，即使他们已经过身份验证）

最后，最后一个块被配置为表单身份验证。

但是有一些症结。

我必须为我的自定义基本/表单和 Kerberos 提供程序全局配置身份验证管理器。 另外，我确实必须像this link suggests 那样配置我的身份验证管理器bean。可能是由于我创建的 xml/java 配置拼凑在一起造成的。 IE 也很奇怪。在我的 kerberos 链中，我还配置了一个登录表单。这允许符合链条件的用户直接导航到登录表单进行身份验证；或者如果有人未能通过我的 Kerberos 用户名检查，我可以将他们转发到登录页面。这适用于 FireFox，但即使在我的服务器发送重定向之后，IE 也会继续发送 Negotiate 标头。基本上，用户无法通过 kerberos，重定向到登录页面，但 IE 仍然会发送 Kerberos 令牌。这会导致来自 Spring Security 的 SpnegoAuthenticationProcessingFilter 再次触发并验证 Kerberos 令牌，当然这会再次失败，并向用户发送继续循环的登录页面。

总的来说，Spring Security 允许 3 个漂亮、相当干净的块，它们都执行各种不同的身份验证/授权，然后它们协同工作，为我们的 Web 应用程序提供相同的用户上下文对象。