Spring 与基本链接的安全 Kerberos
Spring Security Kerberos chained with basic
我有一个关于 Spring 安全的快速问题。
我正在寻找一种将安全性集成到我们的应用程序中的解决方案，该应用程序提供 SSO，但也提供基本的 HTTP。
我们系统的一个自动化部分只能支持基本身份验证，我们被它束缚住了。目前，我们的目标是将 Kerberos 用于我们的 SSO 解决方案，然后还支持基本（非常受限的使用）。所有这些都将通过 resteasy 保护 RESTful 运行 的 Web 服务。
有没有人看到在 spring 安全性中将 Kerberos 和 BASIC 链接在一起的解决方案有任何内在的不可能性？ 我们在 WildFly 和 undertow 方面遇到了问题无法支持多种不同的身份验证方法，在握手中使用 HTTP 响应代码。
感谢您的输入
由于这个问题有点难，我假设您已经熟悉 Spring Security Kerberos samples，其中展示了如何使用表单身份验证作为后备来配置 kerberos 身份验证。
我没有证据表明它会起作用，但我认为您应该能够毫无问题地将您的 kerberos 身份验证与基本身份验证链接起来。我分享我对此的看法...
想法 1：FilterChains
支持多种身份验证方法的诀窍是正确设置身份验证过滤器的顺序。
如果顺序错误，客户端可能会在基本身份验证中挂起，并且可能永远无法到达 kerberos 身份验证过滤器，因为浏览器的基本身份验证对话框会弹出。这可能有点取决于 Spring 中基本身份验证提供程序和过滤器的实现方式。不管怎样，如果顺序是正确的，在 kerberos 过滤器（基本授权过滤器）之后链中的下一个过滤器将开始工作。
想法 2：Kerberos 身份验证不应破坏基本身份验证
浏览器应将与 kerberos 服务提供商的通信与与基本身份验证提供商的通信区别对待，因为协议不同。
SAML 通信在 it's own namespace 中运行，因此我认为它不应该影响基于 HTTP header 中授权元素的基本身份验证通信。
编辑： 即使关于命名空间的假设在浏览器行为中没有任何作用，sequence diagram 中的第 6 步也会成为关键点。当过滤器链接正确时，Spring 应该 return 像 401 - Access denied - WWW-authenticate - Basic realm = "your domain" 这样的 401 响应，这将强制您的浏览器进入基本身份验证。
想法 3：在 Spring 安全 Kerberos
中进行 Spnego 协商
Spnego configuration in the Spring Security Kerberos documentation is acutally build upon those thoughts. This can be seen in the samples, too, in line 49 and 50 of this WebSecurityConfig.java
如果您遇到麻烦，我会很惊讶。
最后的想法
如果没有要求强制您进行基本身份验证，我建议您不要使用它。最好继续使用基于令牌的身份验证。即使我不完全同意这个博客的所有细节，它也解释了 why basic auth shouldn't be used，如果你能避免的话。
我强烈建议您阅读 Mika 的回答。做得很好，给了我前进的信心。
最终这成功了；但我会解释我遇到的几个症结点。
我使用请求匹配器将我的调用分成不同的 HTTP configuration blocks
在订单 1 中，我配置了一个块以通过用户代理过滤来自特定工具的请求。在那个块中，我基本上以标准的 OOTB 方式配置了基本身份验证。不过，我确实编写并提供了自己的身份验证提供程序，该提供程序调用了我们用来通过用户名/密码管理用户的底层系统。
然后，在顺序 2 中，我配置了一个块来处理 Kerberos。在与 Kerberos 提供程序配置搏斗并提出一个在我们的底层系统中进行身份验证的方案之后，这一切都处理得很好。从 Kerberos 获取连接到我的 Web 应用程序的域用户的用户名后，我检查该用户名是否在 my 系统中。如果是，我们将他们登录。如果不是，我们将他们引导至登录页面。 （并非每个域用户都被授权使用我们的网络应用程序，即使他们已通过身份验证）
最后，最后一个块配置为表单认证。
但有一些症结所在。
- 我必须为我的自定义 basic/form 和 Kerberos 提供程序全局配置身份验证管理器。
- 另外，作为旁注，我确实必须像 this link suggests 那样配置我的身份验证管理器 bean。可能是由于我创建的 xml/java 配置拼凑而成。
- IE 也很奇怪。在我的 kerberos 链下，我还配置了一个登录表单。这允许符合链资格的用户直接导航到登录表单进行身份验证；或者如果有人没有通过我的 Kerberos 用户名检查，我可以将他们转发到登录页面。这在 FireFox 上运行良好，但即使在我的服务器发送重定向后，IE 仍继续发送协商 header。基本上，用户使 kerberos 失败，重定向到登录页面，但 IE 仍然发送 Kerberos 令牌。这导致 Spring 安全性中的 SpnegoAuthenticationProcessingFilter 再次触发并验证 Kerberos 令牌，当然这再次失败，并向用户发送继续循环的登录页面。
总结 Spring 安全允许 3 个漂亮、相当干净的块，它们都执行各种不同的身份验证/授权，然后它们协同工作以向我们提供相同的用户上下文 object网络应用程序。
我有一个关于 Spring 安全的快速问题。
我正在寻找一种将安全性集成到我们的应用程序中的解决方案，该应用程序提供 SSO，但也提供基本的 HTTP。
我们系统的一个自动化部分只能支持基本身份验证，我们被它束缚住了。目前，我们的目标是将 Kerberos 用于我们的 SSO 解决方案，然后还支持基本（非常受限的使用）。所有这些都将通过 resteasy 保护 RESTful 运行 的 Web 服务。
有没有人看到在 spring 安全性中将 Kerberos 和 BASIC 链接在一起的解决方案有任何内在的不可能性？ 我们在 WildFly 和 undertow 方面遇到了问题无法支持多种不同的身份验证方法，在握手中使用 HTTP 响应代码。
感谢您的输入
由于这个问题有点难，我假设您已经熟悉 Spring Security Kerberos samples，其中展示了如何使用表单身份验证作为后备来配置 kerberos 身份验证。 我没有证据表明它会起作用，但我认为您应该能够毫无问题地将您的 kerberos 身份验证与基本身份验证链接起来。我分享我对此的看法...
想法 1：FilterChains
支持多种身份验证方法的诀窍是正确设置身份验证过滤器的顺序。 如果顺序错误，客户端可能会在基本身份验证中挂起，并且可能永远无法到达 kerberos 身份验证过滤器，因为浏览器的基本身份验证对话框会弹出。这可能有点取决于 Spring 中基本身份验证提供程序和过滤器的实现方式。不管怎样，如果顺序是正确的，在 kerberos 过滤器（基本授权过滤器）之后链中的下一个过滤器将开始工作。
想法 2：Kerberos 身份验证不应破坏基本身份验证
浏览器应将与 kerberos 服务提供商的通信与与基本身份验证提供商的通信区别对待，因为协议不同。 SAML 通信在 it's own namespace 中运行，因此我认为它不应该影响基于 HTTP header 中授权元素的基本身份验证通信。
编辑： 即使关于命名空间的假设在浏览器行为中没有任何作用，sequence diagram 中的第 6 步也会成为关键点。当过滤器链接正确时，Spring 应该 return 像 401 - Access denied - WWW-authenticate - Basic realm = "your domain" 这样的 401 响应，这将强制您的浏览器进入基本身份验证。
想法 3：在 Spring 安全 Kerberos
中进行 Spnego 协商Spnego configuration in the Spring Security Kerberos documentation is acutally build upon those thoughts. This can be seen in the samples, too, in line 49 and 50 of this WebSecurityConfig.java
如果您遇到麻烦，我会很惊讶。
最后的想法
如果没有要求强制您进行基本身份验证，我建议您不要使用它。最好继续使用基于令牌的身份验证。即使我不完全同意这个博客的所有细节，它也解释了 why basic auth shouldn't be used，如果你能避免的话。
我强烈建议您阅读 Mika 的回答。做得很好，给了我前进的信心。
最终这成功了；但我会解释我遇到的几个症结点。
我使用请求匹配器将我的调用分成不同的 HTTP configuration blocks
在订单 1 中，我配置了一个块以通过用户代理过滤来自特定工具的请求。在那个块中，我基本上以标准的 OOTB 方式配置了基本身份验证。不过，我确实编写并提供了自己的身份验证提供程序，该提供程序调用了我们用来通过用户名/密码管理用户的底层系统。
然后，在顺序 2 中，我配置了一个块来处理 Kerberos。在与 Kerberos 提供程序配置搏斗并提出一个在我们的底层系统中进行身份验证的方案之后，这一切都处理得很好。从 Kerberos 获取连接到我的 Web 应用程序的域用户的用户名后，我检查该用户名是否在 my 系统中。如果是，我们将他们登录。如果不是，我们将他们引导至登录页面。 （并非每个域用户都被授权使用我们的网络应用程序，即使他们已通过身份验证）
最后，最后一个块配置为表单认证。
但有一些症结所在。
- 我必须为我的自定义 basic/form 和 Kerberos 提供程序全局配置身份验证管理器。
- 另外，作为旁注，我确实必须像 this link suggests 那样配置我的身份验证管理器 bean。可能是由于我创建的 xml/java 配置拼凑而成。
- IE 也很奇怪。在我的 kerberos 链下，我还配置了一个登录表单。这允许符合链资格的用户直接导航到登录表单进行身份验证；或者如果有人没有通过我的 Kerberos 用户名检查，我可以将他们转发到登录页面。这在 FireFox 上运行良好，但即使在我的服务器发送重定向后，IE 仍继续发送协商 header。基本上，用户使 kerberos 失败，重定向到登录页面，但 IE 仍然发送 Kerberos 令牌。这导致 Spring 安全性中的 SpnegoAuthenticationProcessingFilter 再次触发并验证 Kerberos 令牌，当然这再次失败，并向用户发送继续循环的登录页面。
总结 Spring 安全允许 3 个漂亮、相当干净的块，它们都执行各种不同的身份验证/授权，然后它们协同工作以向我们提供相同的用户上下文 object网络应用程序。