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: NEW
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: 2019-05-13 16:07 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:


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

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.

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