是否可以进行可选的kerberos身份验证？
我想要的是：如果客户端（浏览器）不在域上，则会将其重定向到用户名/密码Web登录。否则它将执行SPNEGO执行Kerberos身份验证。
如果我只是将WWW-Authenticate：Negotiate标头发送到非域浏览器，它就不会再做任何事了。
如果它不知道如何进行身份验证，是否有一些选项可以告诉浏览器尝试不同的东西？或者，在发送“WWW-Authenticate”标题之前，我是否必须确定用户是否属于域名？
答案 0 :(得分：5)
我没有找到任何人以标准的方式公开解决这个问题。是的，如上所述，可以回退到Basic，但这不适用于涉及从CGI表单请求用户名和密码的身份验证方案，在浏览器看到的情况下，您正在退回如果Negotiate失败，则否身份验证。也许这表明认证方案已被破坏？我不知道。
我先告诉你我所知道的。我们的网站实际上是受Cosign保护的，因此我们遇到了类似的问题：只有特殊配置的计算机会响应WWW-Authenticate标头，因此默认情况下我们必须将所有用户发送到我们的Cosign登录页面。诀窍在于，Cosign服务器还允许经过身份验证的GSSAPI / Kerberos主机完成身份验证过程，而无需输入登录详细信息，但仅限于某些浏览器，通过解决方法。
此解决方法仅包含登录页面中的一个JavaScript块，它尝试HEAD受SPNEGO保护的资源;如果成功，脚本会将浏览器重定向到同一页面的受SPNEGO保护的版本，该版本会授予相应的Cosign cookie并在不输入密码的情况下完成该过程。如果浏览器缺少JavaScript，Kerberos支持或足够的凭据，那么用户将照常看到cosign登录页面。
因此，仅凭上述内容可能算作您问题的答案;个人虽然我认为这远远不够，接下来的讨论更多......
上述内容似乎并不令人满意，因为它坚持认为任何连接用户代理都支持JavaScript（基于文本的浏览器和HTTP客户端库不太可能）或者我们重定向Kerberos用户的任意路径的知识（无用）对我们网站没有硬编码的任何东西）。我得出的结论是，可能有一个更好的解决方法，或者如果没有，那么标准应该是一个差距。我有最好的实际建议是：
SPNEGO流程的正常部分是客户端尝试检索其初始响应为HTTP 401但标题为WWW-Authenticate: Negotiate的页面。这是GSSAPI / Kerberised客户端适当响应的提示; “常规”客户端只会显示错误页面。也许解决方案只是修改Cosign服务器以提供人性化的登录页面作为此错误响应的一部分？
答案 1 :(得分：0)
另外发送WWW-Authenticate: Basic用于用户名/密码质询。