Bug 47242 - Several browsers: Fallback to saml/ldap only after browser password popup
Several browsers: Fallback to saml/ldap only after browser password popup
Status: RESOLVED WONTFIX
Product: UCS
Classification: Unclassified
Component: SAML
UCS 4.3
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on: 46576
Blocks: 46579
  Show dependency treegraph
 
Reported: 2018-06-25 13:35 CEST by Jürn Brodersen
Modified: 2021-05-14 16:34 CEST (History)
3 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 3: A User would likely not purchase the product
User Pain: 0.103
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jürn Brodersen univentionstaff 2018-06-25 13:35:45 CEST
+++ This bug was initially created as a clone of Bug #46576 +++

The negotiate module used in simplesamlphp supports a fallback mode if no kerberos ticket is presented by the browser.

When using Chrome (65.0.3325.146), a popup asking for credentials is shown instead. When clicking cancel, the fallback login page for single sign-can be accessed.

Workaround: deactivate saml/kerberos: ucr set saml/idp/authsource=univention-ldap
Comment 1 Jürn Brodersen univentionstaff 2018-06-25 13:36:27 CEST
Bug 46576 only applied the workaround
Comment 3 Michel Smidt 2019-05-05 22:18:13 CEST
I was just testing and doing some research with support from Florian (thx!)

- The WWW-Authenticate-Header "Negotiate" can be used for Kerberos and NTLM authentication.
- simplesamlphp supports Kerberos authentication only
- However, the Windows clients switch automatically to NTLM as fallback if they cannot use Kerberos due to a missing domain: https://forums.iis.net/t/1151327.aspx?Force+Kerberos+only+authentication+ - 
- Or the Windows clients try to log in with a Kerberos ticket from their own different domain.
- In both cases, this pop-up dialog appears, which is a deterrent to users.
- The problem is that browsers IE, Edge & Chrome already display the dialog before even starting the negotiation (https://tools.ietf.org/html/rfc4559#section-5). As a server, you cannot force (secure) Kerberos authentication.
- I see two solutions and two workarounds all of which are described here: https://github.com/simplesamlphp/simplesamlphp/blob/master/modules/negotiate/docs/negotiate.md#negotiate-module

Solutions:
Solution 1: The browser manufacturers support process which is described in RFC 4559.

Solution 2: Somehow force Kerberos authentication.
The solution would be to send the first response of the server (HTTP/1.1 401 Unauthorized + WWW-Authenticate: Negotiate) with the message that NTLM is not supported. 
- But the standard doesn't seem to support this.

Workarounds:
Workaround 1: Set a cookie which clients have to get the header (WWW-Authenticate: Negotiate) and which does not: https://github.com/simplesamlphp/simplesamlphp/blob/master/modules/negotiate/docs/negotiate.md#enablingdisabling-negotiate-from-a-web-browser
- Already pointed out by Erik
- One would combine this with a unique landing page with selection (SSO yes/no) for users.

Workaround 2: Send the header (WWW-Authenticate: Negotiate) only to clients that are in a certain subnet.
- For this all internal/school Windows clients of the domain must be in certain subnets. Fortunately, this is mostly the case. 
- To Computers from these subnets one can only send the header: https://github.com/simplesamlphp/simplesamlphp/blob/master/modules/negotiate/docs/negotiate.md#subnet-filtering


The second workaround seems to me to be the easiest to implement for now.
All we have to do is support another configuration variable ('subnet' => [ XY ]).
Additionally I will create this as a bug at the browser manufacturers. I could imagine that such a bug will be closed directly because there are probably some other use cases that prevent a change of the behavior but the RFC 4559 described process does not correspond to this from my point of view.
Comment 4 Michel Smidt 2019-05-13 16:07:00 CEST
I have looked still intensively together with my colleagues on it and we have come to the conclusion that it is a misbehaviour of the browsers. That's why I submitted a bug to the Chromium project: https://bugs.chromium.org/p/chromium/issues/detail?id=962473
Comment 5 Ingo Steuwer univentionstaff 2021-05-14 15:41:34 CEST
This issue has been filed against UCS 4.3.

UCS 4.3 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.