是否可以做可选的kerberos认证？
我想要的是：如果客户端（浏览器）不在域名上，它将被重定向到用户名密码网页登录。否则，它将做SPNEGO做Kerberos认证。
如果我只是发送WWW-Authenticate: Negotiate header to a non domain browser it just does nothing further.
如果浏览器不知道如何验证，有没有什么选项可以告诉它尝试一些不同的方法？或者我必须在发送 "WWW-Authenticate "头之前确定用户是否是域的一部分？
我还没有找到任何一个人以标准的方式公开解决这个问题。 是的，如前所述，人们可以回落到 Basic 但这对于涉及从 CGI 表单中请求用户名和密码的验证方案来说是行不通的，在浏览器看来，你会回到 没有 鉴别 Negotiate 失败。 也许这就暗示着认证方案被破坏了？ 我不知道，我先告诉你我知道的 I don't know.
我先告诉你我所知道的。 我们的网站实际上是有Cosign保护的 所以我们有一个和你类似的问题 只有经过特殊配置的机器才会响应你的要求 WWW-Authenticate 头，所以默认情况下，我们必须将所有用户发送到我们的Cosign登录页面。 诀窍是，Cosign服务器也允许经过认证的GSSAPIKerberos主机在不输入登录信息的情况下完成认证过程，但只在某些浏览器上，通过一种变通方法。
这个变通方法包括在登录页面中的一个JavaScript块，该块试图通过以下方式进行验证 HEAD 的SPNEGO保护资源；如果成功，该脚本将浏览器重定向到同一页面的SPNEGO保护版本，该版本将授予适当的Cosign cookie，并在不输入密码的情况下完成该过程。 如果浏览器缺乏JavaScript、Kerberos支持或足够的凭证中的任何一项，那么用户将照常看到cosign登录页面。
所以，上面的内容就可以算作是对你问题的一个回答，不过我个人认为这还不够，下面更多的是讨论......
上面的内容似乎并不令人满意， 因为它坚持要求任何连接用户的代理必须支持 JavaScript (对于基于文本的浏览器和 HTTP 客户端库来说， 这种情况不太可能发生)， 或者知道我们将 Kerberos 功能的用户重定向到哪条任意路径 (对于任何没有为我们的站点硬编码的东西来说都是无用的)。 我得出的结论是，也许有更好的变通办法，或者说，如果没有，也应该有一个标准的空白。 我最好的实际建议是这样的。
SPNEGO程序的一个正常部分是 客户端尝试检索一个页面 其初始响应是一个HTTP 401 但标题为 WWW-Authenticate: Negotiate. 这是GSSAPIKerberised客户端做出适当响应的提示；而 "普通 "客户端只会显示错误页面。 也许解决方案就是简单地修改Cosign服务器，将人性化的登录页面作为错误响应的一部分。
它 可能 对于现成的Apache和模块来说，在技术上是很困难的，而且可能会违背各种标准（或至少是原则）。 我不是相关系统的专家，所以只能推测，除非（或直到）我有机会尝试一下......
另外发送 WWW-Authenticate: Basic 为用户名密码挑战。