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