是否可以进行可选的kerberos身份验证？
我想要的是:如果客户端(浏览器)不在域上,它将被重定向到用户名/密码Web登录.否则它将执行SPNEGO执行Kerberos身份验证.
如果我只是将WWW-Authenticate:Negotiate标头发送到非域浏览器,它就不会做任何进一步的操作.
如果它不知道如何进行身份验证,是否有一些选项可以告诉浏览器尝试不同的东西？或者,在发送"WWW-Authenticate"标头之前,我是否必须确定用户是否属于域？
我没有找到任何人以标准的方式公开解决这个问题.是的,正如所提到的,人们可以回归,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服务器以提供人性化的登录页面作为此错误响应的一部分？
这可能与关闭的,现成的Apache和模块技术上的困难,而且可能不利于各种标准(或至少是原则).我不是所涉系统的专家,所以只能推测除非(或直到)我有机会尝试一下......
| 归档时间： |
|
| 查看次数： |
2301 次 |
| 最近记录： |