可选的SPNEGO Kerberos身份验证 [英] Optional SPNEGO Kerberos authentication

问题描述

是否可以进行可选的kerberos身份验证?

Is it possible to do optional kerberos authentication?

我想要的是:如果客户端(浏览器)不在域中，它将被重定向到用户名/密码Web登录名.否则，它将使用SPNEGO进行Kerberos身份验证.

What I want is: if the client (browser) is not on the domain it is redirected to a username/password web login. Otherwise it will do SPNEGO do Kerberos authentication.

如果我只是将WWW-Authenticate:Negotiate标头发送到非域浏览器，则它只会做进一步的事情.

If I just send the WWW-Authenticate: Negotiate header to a non domain browser it just does nothing further.

如果不知道如何进行身份验证，是否可以告诉浏览器尝试其他操作?还是在发送"WWW-Authenticate"标头之前必须确定用户是否属于域?

Is there some option to tell the browser to try something different if it doesn't know how to authenticate? Or do I have to determine if user is part of the domain before sending the "WWW-Authenticate" header?

推荐答案

我还没有人找到以公开的方式公开解决此问题的人.是的，如前所述，可能会退回到Basic，但这不适用于身份验证方案，该方案涉及从CGI表单请求用户名和密码，就浏览器而言，您会退回<如果Negotiate失败，则为em> no 身份验证.也许这表明身份验证方案已损坏?我不知道.

I haven't found anynone who has solved this publicly and in a standard way. Yes, as mentioned, one could fall back to Basic but that doesn't work for authentication schemes which involve requesting a username and password from a CGI form where, as far as the browser sees things, you're falling back to no authentication if Negotiate fails. Maybe that is suggestive that the authentication scheme is broken? I don't know.

我先告诉你我所知道的.我们的网站实际上是受Cosign保护的，因此我们遇到与您类似的问题:仅特殊配置的计算机会响应WWW-Authenticate标头，因此默认情况下，我们必须将所有用户发送到我们的Cosign登录页面.诀窍在于，Cosign服务器还允许通过身份验证的GSSAPI/Kerberos主机完成身份验证过程，而无需输入登录详细信息，而只能通过某些解决方法在某些浏览器上输入.

I'll tell you what I know, first. Our site is, effectively, Cosign-protected, so we have a similar problem to you: only specially-configured machines respond to the WWW-Authenticate header, so by default we must send all users to our Cosign login page. The trick is that the Cosign server also allows authenticated GSSAPI/Kerberos hosts to complete the authentication process without entering login details, but only on certain browsers, by means of a workaround.

此解决方法仅由登录页面内的JavaScript块组成，该JavaScript块尝试对受SPNEGO保护的资源进行HEAD；如果成功，该脚本会将浏览器重定向到同一页面的受SPNEGO保护的版本，该版本将授予适当的Cosign cookie，并无需输入密码即可完成该过程.如果浏览器缺少JavaScript，Kerberos支持或适当的凭据中的任何一种，则用户将照常看到cosign登录页面.

This workaround consists simply of a block of JavaScript within the login page which attempts a HEAD of an SPNEGO-protected resource; if successful, the script redirects the browser to an SPNEGO-protected version of the same page, which grants appropriate Cosign cookies and completes the process without password entry. If the browser lacks any one of JavaScript, Kerberos support or adequate credentials, then the user will see the cosign login page as usual.

因此，仅上述一项就可以视为您问题的答案；就我个人而言，尽管我认为这还远远不够，接下来是更多的讨论...

So, the above alone might count as an answer to your question; personally though I don't think this goes far enough and what follows is more of a discussion...

上面的内容似乎并不令人满意，因为它坚持认为任何连接的用户代理都支持JavaScript(基于文本的浏览器和HTTP客户端库不太可能支持)或我们将支持Kerberos的用户重定向到的任意路径的知识(无用)到没有为我们的网站进行硬编码的任何内容).我得出的结论是，可能有更好的解决方法，或者如果没有，则应该是标准之间的差距.我的最佳实用建议是:

The above seems unsatisfactory as it insists that any connecting user agent supports either JavaScript (unlikely to be the case for text-based browsers and HTTP client libraries) or knowledge of the arbitrary path to which we redirect Kerberos-capable users (useless to anything which has not been hard-coded for our site). I've come to the conclusion that there might be a better workaround, or if not, a gap where a standard should be. The best practical suggestion I have is this:

SPNEGO过程的正常部分是客户端尝试检索其初始响应为HTTP 401但标头为WWW-Authenticate: Negotiate的页面.这是GSSAPI/Kerberos客户端正确响应的提示； 常规"客户端将仅显示错误页面.也许解决方案只是修改Cosign服务器以提供人性化的登录页面，作为此错误响应的一部分?

A normal part of the SPNEGO process is that the client attempt to retrieve a page whose initial response is an HTTP 401 but with the header WWW-Authenticate: Negotiate. This is the cue for a GSSAPI/Kerberised client to respond appropriately; a "regular" client will simply display the error page. Perhaps the solution is simply to modify the Cosign server to deliver the human-friendly login page as part of this error response?

在现成的Apache和模块上可能在技术上很困难，并且可能违反各种标准(或至少是原则).我不是所涉系统的专家，因此只能推测，除非(或直到)我有机会尝试一下...

It might be technically difficult with off-the-shelf Apache and modules, and might go against various standards (or at least principles). I'm no expert on the systems involved, so can only speculate unless (or until) I get a chance to try it out...

这篇关于可选的SPNEGO Kerberos身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！