1699283 - When multiple WWW-Authenticate Headers are present in an HTTP 401 response, Firefox does not evaluate from strongest to weakest authentication types like other browsers.

Status: RESOLVED DUPLICATE of bug 650091

(Core :: Networking: HTTP, defect, P2)

Description

[Keith]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Consider an IIS webserver which requires authentication. The IIS application developer is sending 3 WWW-Authenticate Headers in its HTTP 401 response as so:
WWW-Authenticate Header is present: Basic Realm="The Portal"
WWW-Authenticate Header is present: Negotiate
WWW-Authenticate Header is present: NTLM

Chrome (and subsequently Chromium based Edge), and Internet Explorer with the site in "Trusted Sites" will evaluate that all three of these headers exist, and then attempt to authenticate from strongest to weakest authentication. In this case I'm seeing Chrome and Edge authenticate in Negotiate (Kerberos), and IE in NTLM. Those browsers do not prompt and assume the current domain logged on identity for the web application.

Actual results:

In Firefox instead of evaluating the WWW-Authenticate headers by order of strongest to weakest authentication method, it evaluates it in order from top to bottom. So in the example above you will immediately be prompted for credentials for Basic Realm "The Portal". If you cancel out twice, it moves to the next WWW-Authenticate Header Negotiate, and in my environment successfully negotiates via a Kerberos ticket as identified in klist tickets (and also in a fiddler trace).

Expected results:

I would have expected the browser to prefer logic where it attempts to authenticate via the most secure method presented available by the webserver, and then fail back to lesser secure methods if it was unsuccessful.
In my application I would have expected a single sign on via a kerberos ticket, or a single sign on via an NTLM hash if I configured my Kerberos SPN incorrectly (or another Kerberos related issue). I would not have expected a basic authentication prompt since that is the weakest (and not secure at all if you do not use HTTPS / TLS 1.2). Other browsers seem to honor the WWW-Authenticate Headers based on security not order in which the webserver replies.

Comment 1

[Mike Kaply [:mkaply]]

Full conversation and diagnosis is here if you want to see the history - https://support.mozilla.org/en-US/questions/1329024

Comment 2

[Daniel Veditz [:dveditz]]

Same issue for Proxy-Authenticate header is bug 650091, and if we fix one we should fix both.

In the last weeks of the Bush vs. Gore presidential election this is how we interpreted the specs available at the time (see bug 44041 comment 21), although even then it turned out to be somewhat ambiguous.

Comment 3

[Valentin Gosu [:valentin] (he/him)]

Thank you for the context Mike and Daniel. Quite useful.

A user agent should choose as the challenge to be made to the user the first one that the user agent understands.

There seems to be some flexibility here. And given that other UAs do it differently, maybe we should follow.

Comment 4

[captjlp78]

I have the same issue in my corporate environment regarding a central SSO login portal and therefore can confirm it, instead of using kerberos a basic auth prompt is displayed first which you have to cancel until kerberos is being used because of the order of the WWW-Authenticate headers in the 401 response:

Firefox ESR 78.10.1

User-Agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

WWW-Authenticate: Basic realm=""
WWW-Authenticate: Negotiate

I'd like to add that this bug is not supporting/advertising the use of Firefox in (SSO) corporate environments because currently users are forced to use other browsers than Firefox if you wanna have a working seamless (kerberos based) SSO experience, solving this issue would make Firefox much more attractive for corporate use.

Comment 5

[Mike Kaply [:mkaply]]

Valentin: Can you give me some pointers on how to fix this?

I was thinking maybe here

https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#183

But I don't understand why GetWWWChallenges is only returning one challenge. Am I missing something?

Comment 6

[Valentin Gosu [:valentin] (he/him)]

This is a dupe of bug 650091.
I will likely land the fix today.

Comment 7

[Mike Kaply [:mkaply]]

Is this one still going to happen?

Comment 8

[Valentin Gosu [:valentin] (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #7)

Is this one still going to happen?

I think so.

Comment 9

[Valentin Gosu [:valentin] (he/him)]

Fixed in bug 650091.