On Tue, Oct 26, 2021 at 2:34 PM Sasha Tokarev <[email protected]> wrote:
> I think it is true for any authentication that part of Chrome, like > Digest, Client TLS, Windows Integrated (NTLMv2, Kerberos) etc. I think the > cookie cleanup will not prevent a web site that performs Windows Integrated > authentication to know who you are. In this aspect it is a new form of > Windows Integrated authentication, but more secure. I think Chrome > implements Windows Integrated authentication as well as other forms of > authentication, and not really concerned about it. From the other hand, a > web app that integrated with IDP will lost its cookies and state on the > cookie cleanup, and will have to start authentication process again, > redirect to IDP, account consent if needed, etc. We also can discuss how we > can support different browser profiles in this area. > The comparison here to the other forms of OS auth is totally apt. However, note that Chrome has already moved (similar to Edge) to restrict/disallow this in Incognito, and there have long been discussions about moving the entire authentication stack itself behind policy-gates, precisely because for the general user, it represents a privacy and security risk. Some of that calculus is further informed by the openness and well-definedness of the protocols implemented, and the ability to assess their relative security merits; e.g. NTLM is seen as a greater security risk to users due to its limits on "server" authentication, compared to Kerberos (e.g. via SPN binding). And, similarly, Negotiate is seen as a risk because of the ability to introduce mechanisms that may otherwise contravene local policies (e.g. if you disable NTLM, but the Negotiate provider still enables it). Of course, the existing auth methods also reveal some of the complexity I worry about. NTLM/Kerberos/Negotiate using a three-leg auth system means that it's incompatible with HTTP/2 and, similarly, incompatible with HTTP/3. This creates a fair bit of negative incentives for organizations: you can have a modern application, or you can have integrated SSO, but you can't have both. Of course, that realization of incompatibility was only possible due to the fairly open and extensive documentation of the protocols. I don't mean this to sound too negative; again, you've been incredibly helpful :) It's just one of those headwinds to be mindful of in trying to figure out how to rationalize this, since as a "cookie-or-header" side, there are plenty of implementation worries. It looks like Mozilla had similar concerns - e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1695693#c9 and https://phabricator.services.mozilla.com/D114540#3798290 , so I feel a little better :) They also highlighted an area of reasonable concern regarding IDNA treatment that I totally overlooked too, not to mention the header correctness. > Overall, I would like to highlight this model is not only about SSO, SSO > is a tip of the iceberg, we build a lot of features on it: > > > > 1. Conditional access — granular control of access to the cloud > resources (mentioned above). > 2. Enables protection of Identity artifacts against man-in-the-middle > attacks by allowing Identity provider to issue shorter lived tokens that > are bound to the device identity. > 3. Preventing extra password and 2FA prompt, minimizes the need for > sending user’s password on the wire continuously. > > Right, but these are both benefits and risks. Not trying to be contrarian so much as capture a different perspective, but conditional access can be also viewed as a form of browser/vendor lock-in (which, as you note, may already be practiced, but not necessarily good), the binding to device identity equally normalizes persistent online tracking in ways that may be coopted for less-than-noble purposes (e.g. attempts to legislate out online anonymity), and while you're certainly correct that reducing prompts is a great way to reduce fatigue while improving the security story for the underlying auth, the primary way of doing that is through encouraging greater centralization of identity services. These aren't to discredit the idea, but to highlight the risks, and the challenge in finding the balance. > 1. Missing documentation – we Microsoft, planning to publish code on > github and fix documentation, to allow other browser to integrate. > 2. X-ms- headers – if needed we can agree on different header names, > or remove x-ms- prefix 😊 > > It looked like Mozilla also raised this concern, so it seems to be a clear need to address. > “This sort of thing doesn't have a path towards standardization or > interoperability” — at this stage, other players already integrated with > it, or have similar model (only Chrome, and Android doesn’t have similar > model). Once we fix the documentation Opera and others will fix their > browsers as well. Our extensions in total have 20M+ users – there is big > demand on this. I don’t think this concern will stop key players, as there > is demand on it. We cannot stop this, but we can lead it. We can work > together on the path forward. However, while we were work on it, I prefer > Chrome users experience a good experience. > > > What would be the next step in this area? Do you have a proposal for the > path forward? > I agree that there's a lot of interesting ideas here, and that have been in the space for a while. If this is solely relegated to an Enterprise flag (and not even a user preference), I certainly am far less worried. My worry, however, is these things always have scope creep and complexities and this is where we have a process for collaboration that's worked very well in the past (e.g. WICG and WHATWG). I realize that, due to the OS integration, that's not always realistic or achievable to work on that, and sometimes "What ships first, ships". I mean, that's how we got SSL, and so it's not all bad (even if SSL 2/3/TLS 1 weren't... the strongest protocols :P) My worry is the pressures to more generally expose this (e.g. a user-level preference or a default-on) will, similar to the "lost decade" of NTLM/Kerberos interop online, end up with a de-facto standard that isn't well defined as to how it integrates. That said, there's useful restrictions highlighted by Mozilla worth further considering if implementing. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvaWvZPVowJx%3DXzXv%2BVSCCiMONwotML2aWZiETXFQO0hbLgtw%40mail.gmail.com.
