Linux Spring Kerberos扩展、SSO和域外机器

我一直在使用Kerberos扩展的里程碑2来实现单点登录

我的设置的快速摘要：
KDC:WindowsServer2003（SP2）
Web服务器：Ubuntu 10.04、Tomcat 5.5、Java 1.6.0_22（不在域中）
Spring:framework3.0.5，Security 3.0.4，Kerberos扩展1.0.0m2

我已将配置设置为首先尝试SPNEGO身份验证，如果失败，则重定向到登录页面。 这是通过设置SPNEGAuthenticationProcessingFilter的“failureHandler”属性来完成的。我已经成功地测试了这个 在域内外的Windows计算机（XP和7）上。域外的计算机被重定向到 登录页面，然后可以成功登录。
这是我的配置：

当Windows计算机在域之外时，我的web服务器会响应“WWW-Authenticate-congregate”标头（按常规），该标头 Windows计算机用NTLM头（“协商TlRM…”）响应，其中SPNEGAuthenticationProcessingFilter然后说“协商头无效…” 并自动将用户重定向到登录页面。太好了

问题：
有许多Mac和Linux机器永久位于域之外，需要使用此web应用程序。 当他们点击web应用程序（使用Firefox 3.6）时，我的web服务器会以预期的“WWW-Authenticate-congregate”标题进行响应以通知 客户端认为web应用程序已被Kerberized，但Mac或Linux机器根本没有响应。因此，SPNEGAuthenticationProcessingFilter 不会再次输入，因此不会出现故障，也不会重新定向到登录页面

问题：
为什么Mac和Linux机器的响应方式与Windows机器的响应方式不同（真不敢相信我刚才问了这个问题…）

我知道，当Mac和Linux机器（通过kinit）获得票证时，它们能够进行身份验证，但这似乎不是一个好的解决方案 因为它需要用户的努力来提供凭证等票据到期的地方

那么有没有办法让这些机器像Windows机器那样发回NTLM头呢？ 或者如果有任何其他建议/方法，请让我知道

---

B.t.w.我确实配置了我用来在Mac和Linux机器上测试的Firefox（“网络.协商授权URI”和“网络.协商授权.可信URI”设置为“.corpza.corp.co.za”）。

看起来不像您设置了network.automatic-ntlm-auth.trusted-uris。你看完了吗

---

Grant

看起来您没有设置network.automatic-ntlm-auth.trusted-uris。你看完了吗

---

格兰特，你走错方向了。不要依赖出现故障的SPNEGO过滤器。Linux和Mac客户端的行为与Windows客户端一样正确。常规设置应该如下所示，如果过滤器没有实现/支持该设置，则表明您发现了一个bug

客户端向服务器发送请求

客户端从服务器（或协商、基本、摘要的任意组合）接收“401 WWW验证：协商”

客户端尝试提供身份验证数据，如果失败，将显示401页

现在，您依靠从Windows客户端发送的错误/不可处理的数据来显示表单。您应该直接将表单与401一起发送，以使所有客户都能够选择适当的登录方法（SPNEGO或表单，即故障通过）。请记住，form auth不像协商、摘要或Basic那样是http auth。必须以不同的方式对待它

---

我们也在使用这个过滤器，我对它不是很满意。所以我有亲身体验。

你走错了路。不要依赖出现故障的SPNEGO过滤器。Linux和Mac客户端的行为与Windows客户端一样正确。常规设置应该如下所示，如果过滤器没有实现/支持该设置，则表明您发现了一个bug

客户端向服务器发送请求

客户端从服务器（或协商、基本、摘要的任意组合）接收“401 WWW验证：协商”

客户端尝试提供身份验证数据，如果失败，将显示401页

现在，您依靠从Windows客户端发送的错误/不可处理的数据来显示表单。您应该直接将表单与401一起发送，以使所有客户都能够选择适当的登录方法（SPNEGO或表单，即故障通过）。请记住，form auth不像协商、摘要或Basic那样是http auth。必须以不同的方式对待它

我们也在使用这个过滤器，我对它不是很满意。所以我有实践经验