HTTP身份验证失败时继续

发布于 2025-02-06 18:56:36 字数 1203 浏览 2 评论 0原文

我创建了一个主要在Windows Intranet上使用的应用程序(后端和前端)。我正在使用Kerberos身份验证进行SSO,以便任何登录到Windows域的人都会自动验证到服务器。为此,我设置了用于服务器和配置的浏览器等的Kerberos SPN,并且在正常情况下都可以正常工作。我的问题是,如果用户未经过身份验证,则需要继续(即从Windows域外部连接或未正确配置其浏览器)。

总而言之,有两种情况:

  1. 如果确定的确定确定继续授予其ID的授权[当前有效],
  2. 如果 认证的验证继续在第一种情况下继续使用(公共)授权[不起作用],则

HTTP请求http请求/响应是: 一个。前端:初始HTTP请求 b。后端:找不到auth,因此返回 401 未经授权> www-authenticate:谈判 header c。前端:使用授权标头重新召集请求 - > 解码以获取登录ID

在第二种情况下 : 一个。前端:初始HTTP请求 b。后端:找不到auth,因此返回 401 www-authenticate:谈判(以及身体中的错误文本) c。前端:浏览器停止(将响应的正文显示为对用户的文本),

这是我需要以某种方式避免浏览器完全避免完全轰炸的问题的关键(如上面的步骤C所示)。

我尝试过的解决方案:

  1. 向用户显示一条有关如何调整浏览器设置以允许SSO在401响应消息正文中工作的消息。这看起来很丑陋,并且不适合从域中的连接

  2. 尝试了301重定向,而不是401个未经授权的响应,但浏览器不喜欢这样。

  3. 401 响应主体中使用JavaScript尝试了重定向,但未执行。

  4. 具有后端发送 401 ,但使用www-authenticate:协商,基本。但是,这显示了一个不需要的登录/密码对话框,如果它们不登录,仍然会失败。

我真正需要的是选项,即:www-authenticate:协商,无,然后如果随后的前端请求表示“无”。 当然,没有一个“无”选项。 :(

看来这应该是一个相当典型的情况,但是我已经研究了3天无济于事。任何建议都将不胜感激。

I have created an app (backend and frontend) that is mainly used on a Windows intranet. I'm using Kerberos authentication to do SSO so that anyone logged in to Windows domain is automatically authenticated to the server. To do this I set up Kerberos SPN for server and configured browsers etc and is all working fine in the normal scenario. My problem is that I need to continue if the user is not authenticated (ie connects from outside the Windows domain or does not have their browser configured correctly).

In summary there are two scenarios:

  1. if authenticated OK continue with authorization granted for their ID [currently works]
  2. if not authenticated continue with no (public) authorization [does not work]

In the first case the HTTP requests/responses are:
a. frontend: initial HTTP request
b. backend: no auth found so return 401 unauthorized with WWW-Authenticate:Negotiate header
c. frontend: re-sends request with Authorization header -> decoded to get the login ID

In the 2nd case:
a. frontend: initial HTTP request
b. backend: no auth found so return 401 with WWW-Authenticate:Negotiate (and error text in the body)
c. frontend: browser stops (displaying the body of the response as text to the user)

This is the crux of the problem I need to somehow avoid the browser just completely bombing (as at step c above).

Solutions I have tried:

  1. display a message to the user about how to adjust browser settings to allow SSO to work in the body of the 401 response message. This is pretty ugly looking and does not work for connections from outisde the domain

  2. Tried a 301 redirect in stead of 401 unauthorized response, but the browser does not like this.

  3. Tried a redirect using javascript in the 401 response body, but it is not executed.

  4. Have the backend send 401 but with WWW-Authenticate:Negotiate,Basic. But this display an unneeded login/password dialog and still fails if they don't login.

What I really need is an None option, ie: WWW-Authenticate:Negotiate,None then continue with no auth if the subsequent frontend request indicate "None" was used.
Of course, there isn't a "None" option. :(

It seems that this should be a fairly typical scenario but I have been researching this to no avail for 3 days now. Any advice would be greatly appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

淡淡離愁欲言轉身 2025-02-13 18:56:36

如果浏览器从Intranet外部连接,则只需继续。那就是根本不会发送401响应(无验证)。您应该可以从它们从何处的IP地址分辨出。

另一个选择是重定向401主体中的页面中使用JS。如上所述,我认为您需要包括content-type:text/htmlcontent-type:text/javascript

If the browser is connecting from outside the intranet then just continue. That is do not send the 401 response at all (no auth). You should be able to tell from the IP address where they connect from.

Another option is to redirect using JS in a page in the 401 body. As mentioned above I think you need to include Content-type: text/html or Content-type: text/javascript.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文