Hi Ryan, Thank you for the chat.
Couple notes from me: > If this is solely relegated to an Enterprise flag (and not even a user > preference), I certainly am far less worried. I think it will be very far from ideal, key part is that the user has joined his device and consented for SSO. They expect SSO. Having extra flag just extra useless hop, which adds friction without value. If users do not want to have SSO, they should not join. Extra policy/switch will kill authentication in Chrome for small businesses, because they will not know how to enable it, many organizations do not have big investment in IT department, as well as they allow use users’ personal devices, on which IT has limited control to enable some flag remotely. As a result it will make Chrome less attractive for such businesses. > there have long been discussions about moving the entire authentication stack > itself behind policy-gates Discussion is one thing, but you haven’t done it, right? As Chrome will lost its attractiveness because IT folks will have to jump via extra hops, most likely will not find how to do it, and user have to switch on working browsers. > … 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. The key difference here from other public auth schemes, that in a public auth protocol there is an assumption that somebody will implement those schemes, and an enterprise can setup a web auth service created by 3p developer. In the new approach it just us, we should validate our stuff, the rest of world integrates with us by OAuth. In a public auth protocol you need an extensive documentation and think what a behavior of web browser should be if an auth web server behavior is not legitimate. In the proposed scheme, you have only couple well-known IDPs, which you can easily identify, the behavior is well defined and documented. You can monitor and contact IDP any time. It is not 1000s of servers who implements kerberos worldwide, it just 2 services. Format/documentation of cookie-header has low relevance here, as it is our internal details. > note that Chrome has already moved (similar to Edge) to restrict/disallow > this in Incognito Totally agree on this! I think we could take Edge’s idea: 1. default/first profile has this feature on. 2. A secondary profile - by default off, but has a setting to turn it on. 3. Incognito – can behave as a secondary or have some registry. We also can discuss how to create profile for a different WebAccounts that you have on the system. > It looks like Mozilla had similar concerns Some of Mozilla concerns are the same, but some are different - I’m aware all of them, as I’m involved in that project as well. Regardless of their concerns - they shipped the first click stop. With respect to documentation/header names, it is important for me to understand your commitments for this. As it is not cheap, if Chrome going to commit in this, we can discuss what is important for you, and do it fast, otherwise we will do it in our own pace. > 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) I have multiple interpretation of this phrase in my head, but I’ll try to respond what I think is the most likely one. If it is about having some client-side code that prevents from some access (client-side security) it easy to work around by patching the code. Whatever we build, as well as some other vendors, we deliver device id to the server, and the server decides “issues/not issues token” based on the state of device, and its history. It is way harder to compromise many signals that comes from device over time vs patching the client code. > 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) I think it is important to highlight here, that IDP knows device (and the user has consented it), but the calling web-application not mandatory (it really depends what IDP renders in the token). I share your device online anonymity (that is why I agree that in Incognito mode we should have this stuff off), but our job is keeping balances between privacy, security, and features. If the user has made the extra steps to join the device to IDP, then I don’t think we should challenge that user made a wrong decision. The users always can unjoin, if they do not trust IDP, or IDP compromised their trust. > the primary way of doing that is through encouraging greater centralization > of identity services. And this where this feature will help 😊 Thank you, Sasha From: Ryan Sleevi <[email protected]> Sent: Tuesday, October 26, 2021 12:03 PM To: Sasha Tokarev <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome On Tue, Oct 26, 2021 at 2:34 PM Sasha Tokarev <[email protected]<mailto:[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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1695693%23c9&data=04%7C01%7Calextok%40microsoft.com%7Cd9a1a8a860a94aa2396d08d998b34dee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637708718200857564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3oeyTSDJC9wMAPAox7guZCjGpgaM7Dghlwe6cSjlihc%3D&reserved=0> and https://phabricator.services.mozilla.com/D114540#3798290<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fphabricator.services.mozilla.com%2FD114540%233798290&data=04%7C01%7Calextok%40microsoft.com%7Cd9a1a8a860a94aa2396d08d998b34dee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637708718200867560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tHdyL%2Bqu36Pg9oJ2QMxZDv6ZHPyfLiXETRtu6IWwQBQ%3D&reserved=0> , 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/BL0PR00MB037247A432E1D6465FABAC2AA18B9%40BL0PR00MB0372.namprd00.prod.outlook.com.
