是否可以进行可选的 kerberos 身份验证？
我想要的是：如果客户端（浏览器）不在域上，它将被重定向到用户名/密码 Web 登录。否则它将执行 SPNEGO 执行 Kerberos 身份验证。
如果我只是将 WWW-Authenticate: Negotiate 标头发送到非域浏览器，它就不会做任何进一步的事情。
如果浏览器不知道如何进行身份验证，是否有一些选项可以告诉浏览器尝试不同的方法？或者我必须在发送“WWW-Authenticate”标头之前确定用户是否是域的一部分？
问问题
2757 次
2 回答
5
我还没有找到任何人以公开和标准的方式解决了这个问题。是的，如前所述，可以回退到Basic但这不适用于涉及从 CGI 表单请求用户名和密码的身份验证方案，就浏览器所见，如果失败，您将回退到不Negotiate进行身份验证. 也许这表明身份验证方案已损坏？我不知道。
我先告诉你我知道的。我们的网站实际上是受 Cosign 保护的，所以我们遇到了类似的问题：只有特殊配置的机器才会响应WWW-Authenticate标头，所以默认情况下，我们必须将所有用户发送到我们的 Cosign 登录页面。诀窍在于，Cosign 服务器还允许经过身份验证的 GSSAPI/Kerberos 主机在不输入登录详细信息的情况下完成身份验证过程，但只能在某些浏览器上通过一种变通方法来完成。
此解决方法仅包含登录页面中的一段 JavaScript，它尝试访问HEAD受 SPNEGO 保护的资源；如果成功，该脚本会将浏览器重定向到同一页面的受 SPNEGO 保护的版本，这会授予适当的 Cosign cookie 并在不输入密码的情况下完成该过程。如果浏览器缺少任何一种 JavaScript、Kerberos 支持或足够的凭据，那么用户将照常看到 cosign 登录页面。
因此，仅以上内容就可以作为您问题的答案；就个人而言，虽然我认为这还远远不够，接下来更多的是讨论......
上述内容似乎并不令人满意，因为它坚持认为任何连接的用户代理都支持 JavaScript（对于基于文本的浏览器和 HTTP 客户端库不太可能是这种情况）或我们将支持 Kerberos 的用户重定向到的任意路径的知识（对于任何尚未为我们的网站进行硬编码）。我得出的结论是，可能有更好的解决方法，或者如果没有，标准应该存在的差距。我最好的实用建议是：
SPNEGO 过程的正常部分是客户端尝试检索初始响应为 HTTP401但带有标头的页面WWW-Authenticate: Negotiate。这是 GSSAPI/Kerberised 客户端做出适当响应的提示；“常规”客户端只会显示错误页面。也许解决方案只是修改 Cosign 服务器以提供人性化的登录页面作为此错误响应的一部分？
使用现成的 Apache 和模块可能在技术上很困难，并且可能违反各种标准（或至少是原则）。我不是所涉及系统的专家，所以只能推测，除非（或直到）我有机会尝试一下......
于 2012-09-26T21:47:38.710 回答
0
额外发送WWW-Authenticate: Basic用户名/密码挑战。
于 2012-06-09T13:36:07.827 回答