我有一个关于 Spring Security 的快速问题。
我正在寻找一种将安全性集成到我们的应用程序中的解决方案，该应用程序提供 SSO，但也提供基本的 HTTP。
我们系统的一个自动化部分只能支持基本身份验证，我们被它锁定了。目前，我们的目标是将 Kerberos 用于我们的 SSO 解决方案，然后还支持基本(非常受限的使用)。所有这些都将保护通过 resteasy 运行的 RESTful Web 服务。
有没有人看到在 spring security 中将 Kerberos 和 BASIC 链接在一起的解决方案存在任何固有的不可能性？我们在 WildFly 和 undertow 方面遇到了问题，无法支持多种不同的身份验证方法，这些方法使用 HTTP握手中的响应代码。
感谢您的意见
最佳答案
由于这个问题有点难，我假设您已经熟悉 Spring Security Kerberos samples显示如何使用表单例份验证配置 kerberos 身份验证作为后备。 我没有证据表明它会起作用，但我认为您应该能够毫无问题地将您的 kerberos 身份验证与基本身份验证链接起来。我分享我对此的看法...
想法 1:过滤器链
支持多种身份验证方法的诀窍是正确设置身份验证过滤器的顺序。 如果顺序错误，客户端可能会在基本身份验证中挂起，并且可能永远无法到达 kerberos 身份验证过滤器，因为浏览器的基本身份验证对话框会弹出。这可能有点取决于基本的身份验证提供程序和过滤器在 Spring 中的实现方式。不管怎样，如果顺序是正确的，在 kerberos 过滤器(基本授权过滤器)之后链中的下一个过滤器将开始工作。
想法 2:Kerberos 身份验证不应破坏基本身份验证
浏览器应该将与 kerberos 服务提供商的通信与与基本身份验证提供商的通信区别对待，因为协议(protocol)不同。 SAML 通信在 it's own namespace 中运行，因此在我看来，它不应该影响基于 HTTP header 中授权元素的基本身份验证通信。
编辑: 即使关于命名空间的假设在浏览器行为中没有发挥任何作用，sequence diagram 中的第 6 步将是一个关键点。当过滤器链接正确时，Spring 应该返回 401 响应，例如 401 - Access denied - WWW-authenticate - Basic realm = "your domain" 这将强制您的浏览器进入基本授权。
思考三:Spring Security Kerberos 中的 Spnego 协商
Spnego configuration在 Spring Security Kerberos 文档中，Kerberos 文档实际上是建立在这些想法之上的。这也可以在示例中看到，在 this WebSecurityConfig.java 的第 49 和 50 行中。
如果您遇到麻烦，我会很惊讶。
最后的想法
如果没有要求强制您进行基本身份验证，我建议您不要使用它。最好继续使用基于 token 的身份验证。即使我不完全同意这个博客的所有细节，它也解释了 why basic auth shouldn't be used ，如果你能避免的话。
关于java - 与基本链接的 Spring Security Kerberos，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30654124/