Hy Ryan, Sorry for the delay and thank you for open discussion.
I would like to start from the simple point: > it means clearing cookies in Chrome may no longer clear cookies, because > these IDP APIs may hold on to them. 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. One part that I haven’t covered yet, that those headers/cookies have device id inside, and admins have tools to enable access to their resources based on the state of device. For example, they can allow to access to SharePoint, only if a user’s device is compliant (has the latest updates and satisfy other company’s requirements). Most Microsoft customers enjoy using conditional access policies to protect their cloud resources. These policies are widely used because they allow granular control of cloud assets. However, if cookies were not reliably delivered, then the users are blocked and entering password will not help — the users will be permanently blocked. The users cannot utilize Chrome as is, because Chrome cannot deliver device information to the identity service for the policy evaluation. Depends on platform, the users have multiple options to unblock themselves: 1. Use Chromium Edge — given that HTML engine is the same between Chrome and Edge they do not lose anything. 2. Use FireFox, which has already integration with this feature ( https://support.mozilla.org/en-US/kb/windows-sso ) 3. Install one of our Chrome extensions (for example this one https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji), which uses native messaging host to integrate with this API. 4. For MacOS, iOS use Safari, as iOS, Apple supports alternative, but similar functionality: ASAuthorizationSingleSignOnProvider | Apple Developer Documentation<https://developer.apple.com/documentation/authenticationservices/asauthorizationsinglesignonprovider?language=objc> WebKit/SOAuthorizationCoordinator.mm at main · WebKit/WebKit (github.com)<https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationCoordinator.mm> With respect to the extension model, it is naturally more complex, because it must consider 3P code, as a result has more failure points. Unfortunately, support story for the extensions is painful for us and our customers, and when we say people escalate to Google, they say that they cannot, and choose other options. Overall Chrome users experience degraded single sign on experience compared to Edge, FireFox or Safari population. They must pass extra 2FA and password prompts, unless they use the extension, while Edge, Safari and FireFox the users can skip these interrupts, if they used strong Windows logon credentials or passed 2FA in other applications (like Teams, Outlook etc.). 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. As you already have noted, FireFox, Safari, Apple platform already supports this feature or similar feature, and we in constant collaboration with them. I agree with you, that there is lack of documentation and standardization, but the key players actively work on this, and it doesn’t stop them. I would like us to focus on the finding path forward, which from one hand will put Chrome on parity with Edge, Safari and FireFox at this aspect, from the other hand will formalize and find a path to close the gaps you mentioned: 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 😊 3. 3P integration — for now there is no 3P, as 3Ps are not willing, and they cannot appear without work on our end. Once 3P will express their interest, we are more than happy to work with them and you on topic you mentioned: * Allow them to use headers vs cookies. * Code isolation. “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? Thank you, Sasha From: Ryan Sleevi <rsle...@chromium.org> Sent: Thursday, October 21, 2021 7:36 AM To: Sasha Tokarev <alex...@microsoft.com> Cc: rsle...@chromium.org; z...@chromium.org; blink-dev@chromium.org; g...@chromium.org; mme...@chromium.org; a...@chromium.org; yhir...@chromium.org; pastarm...@chromium.org Subject: Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome Thanks Sasha! TL;DR: I think we've got enough information here to make a decision. You've been incredibly helpful for that. What follows is my personal views, not a decision, and I share them not to shut down the conversation, but instead, to keep the conversation going and to continue to move us closer to a conclusion :) Speaking personally, I'd be worried about implementing this in Chromium. You've been incredibly helpful here in helping understand, but I worry this highlights a worrying lack of documentation here, as well as a lack of holistic integration into the Web Platform. Extensions obviously have incredible power and flexibility, and can "break" the assumptions of the Web Platform in many ways, to both the delight (e.g. introducing new features) and consternation (e.g. breaking existing features) of users. Yet as extensions, it's also an area where it's "not our problem" to support. That seems like I'm arguing we (Chromium) shouldn't do it because it means more work for us, but that's not quite where I'm going. Rather, to integrate this into Chromium means making sure Chromium developers have the knowledge to understand and reason about how this will interact with the Web Platform, how the Web Platform can co-evolve with features like this, and how it fits overall into Chromium's 4 S's (Simplicity, Speed, Security, Stability). In particular, I think as mmenke@ alluded to, this makes it difficult to reason about privacy properties: for example, it means clearing cookies in Chrome may no longer clear cookies, because these IDP APIs may hold on to them. For things like the effort to safely partition and isolate cookies, this means it's difficult to reason about how these APIs behave in 1P vs 3P contexts. In terms of stability, this seems intended to be an extensible platform, and thus potentially brings more 3P code into whatever process implements this (the proposals, at present, are for the browser process, due to network service sandboxing). When we think about how potential 3P (non-MS) IdPs would use this API, it sounds like that this would de facto mean that they'd need to use "x-ms-" as a prefix for their headers, and that, similarly, there's a lack of way to feed back in to the IdP the state of the user as to whether headers-or-cookies should be used. I appreciate Microsoft's attempt to provide some isolation for the Web from their experimental headers ("x-"), but as RFC 6648 Section 3 highlights, this doesn't really work in practice, and the use of "x-" headers doesn't really prevent them from becoming de facto standards (as the previous remark highlights). My worry is that if directly implemented in Chromium, these all become concerns Chromium needs to worry about, and Chromium needs to support and address. We can't just remove a feature when it gets difficult, or there isn't sufficient documentation, and while I'm not trying to suggest we can arbitrarily break extensions either, we don't necessarily have to reason about every extension's behaviour prior to making any changes to Chromium, like we do need to do with Chromium features. For users, "Chromium is broken", and there's not an option to point out that "no, the extension is broken" as there is today. I do worry that because this flow can only really be implemented in conjunction with Windows (and WAM), it makes it easy for websites to construct experiences that "Work best with Edge" or, if Chromium implements, "Work best with Chromium". For example, if an internal website required these assertions, then they would not work with Firefox - unless the user installed the extension or unless Firefox also integrated with Microsoft's proprietary APIs. While it's certainly true that an internal website (or IdP) could provide a "fallback path" for a "less" secure browser (i.e. one that doesn't provide TPM-bound cookies), I think practical experience of enterprises in the past suggest that may be less likely. I'm very concerned that this sort of thing doesn't have a path towards standardization or interoperability. I realize that, in part, this approach to WAM is a reflection of the fact that Token Binding shared many of these limitations, and we intentionally removed Token Binding precisely because of its incompatibility with, and lack of explaininability with, the overall Web Platform. This is conceptually similar in the challenges, but with even less multi-stakeholder agreement or interoperable specification, and so that does worry me. Similarly, I do worry that this favors a particular IdP being able to offer both technical solutions and ease of use over those of others, both because at least one IdP will always work "out of the box" on some OSes, but also because the access to change those requirements as needed (e.g. the shift from cookies to headers) that other IdPs can't easily do. But that's just my opinion, and I certainly wouldn't be the one to have final say here, especially since I'm known for taking the most critical view ;-) Despite Chromium's reputation within some circles for "shipping early", and to the consternation or objections of other browsers, the reality is both that Microsoft is already shipping this, and that this is already possible, today, with Native Messaging and extensions. So websites can, today, require the installation of the extension, and the friction involved may not be meaningful to prevent network effects. Enterprises can easily push extensions, so they can already deploy fleet wide and build internal sites that are "Chromium only" (and, similarly, to support Firefox through Firefox's WebExtension and native messaging). Similarly, Enterprises can already prohibit other platforms and browsers from being used for their internal sites, so perhaps this isn't the straw that breaks the camel's back. Putting this in Chromium just makes it easy for enterprises to get what they want, makes it easier for them to use more browsers, and maybe that's worth the tradeoffs listed above. And there are plenty of features we'd consider for Enterprises that have no place at all in the Web Platform: in some ways, we let Enterprises break the Web however they want, as long as it's only for their users. The clear alternative would be reopening discussions about Token Binding, and that's a huge investment to do so correctly (as shown by the 5+ year investment from Chrome in unsuccessfully doing that), so perhaps this is the path to split the difference, by de facto adopting Microsoft's since-shipped approach. As you can see, while I'm personally not supportive, I can see clear positives here. I think you've been incredibly helpful getting a good understanding of what the request is, and I think it's certainly worth considering and discussing! I don't think this discussion would have been possible without your support and engagement, so while I'm somewhat negative about the feature in its present form, this isn't a critique of your engagement. Again, thank you, genuinely :) On Thu, Oct 21, 2021 at 12:45 AM Sasha Tokarev <alex...@microsoft.com<mailto:alex...@microsoft.com>> wrote: Hi all, You are correct with respect to cookie size limit. Because there is a 4k limit for all cookies, when we introduced multiple accounts, we hit this limit and some proxies started to block our requests. That why we changed our cookies to headers. Right now, IProofOfPossessionCookieInfoManager::GetCookieInfoForUri can return either a list of cookies or a list of headers. GET https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=1fec8e78-bce4-4aaf-ab1b-5451cc387264&redirect_uri=ms-appx-web%3a%2f%2fMicrosoft.AAD.BrokerPlugin%2f1fec8e78-bce4-4aaf-ab1b-5451cc387264&resource=https%3a%2f%2fapi.spaces.skype.com&add_account=multiple&login_hint=aaa%40microsoft.com&response_mode=form_post&windows_api_version=2.0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3D1fec8e78-bce4-4aaf-ab1b-5451cc387264%26redirect_uri%3Dms-appx-web%253a%252f%252fMicrosoft.AAD.BrokerPlugin%252f1fec8e78-bce4-4aaf-ab1b-5451cc387264%26resource%3Dhttps%253a%252f%252fapi.spaces.skype.com%26add_account%3Dmultiple%26login_hint%3Daaa%2540microsoft.com%26response_mode%3Dform_post%26windows_api_version%3D2.0&data=04%7C01%7Calextok%40microsoft.com%7C7f168beea5484620d03c08d994a021c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637704238197161968%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twGS7GaSTumG1RQuRMfStqzaJ2rshDpy9YuetsOPvWI%3D&reserved=0> HTTP/1.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.21329 x-ms-DeviceCredential: eyJhbGciOiJSUzI1NiIsICJ0eXAiOiJKV1QiLCAieDVjI… x-ms-RefreshTokenCredential: eyJrZGZfdmVyIjoyLCJjdHgiOiIyckJrVzcxQzFCSjg1Q1ZSSWtlWmRmYklReW9… x-ms-DeviceCredential1: eyJhbGciOiJSUzI1NiIsICJ0eXAiOiJKV1QiLCAieDVjI… x-ms-RefreshTokenCredential1: eyJrZGZfdmVyIjoyLCJjdHgiOiIyckJrVzcxQzFCSjg1Q1ZSSWtlWmRmYklReW9… if the name of the cookie starts from x-ms- then this cookie should be added as a header, otherwise as a cookie, please, see attached example: if (_wcsnicmp(tokens[i].name, L"x-ms-", _countof(L"x-ms-")) == 0) { std::wcout << "Add as a header: \n\t" << tokens[i].name << ": " << tokens[i].data << std::endl; } else { std::wcout << "Add as a cookie: \n\t" << tokens[i].name << "==" << tokens[i].data << tokens[i].p3pHeader << std::endl; std::wcout << "\tP3P: " << tokens[i].p3pHeader << std::endl; std::wcout << "\tdwFlags for InternetSetCookieEx: "<< std::hex << tokens[i].flags<< std::endl; // https://docs.microsoft.com/en-us/windows/win32/api/wininet/nf-wininet-internetsetcookieexa<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fapi%2Fwininet%2Fnf-wininet-internetsetcookieexa&data=04%7C01%7Calextok%40microsoft.com%7C7f168beea5484620d03c08d994a021c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637704238197171960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zHqUCLaYn44yrp7qntUPsrvllTdZDM7GFdMgwdhXlFA%3D&reserved=0> } Thank you, Sasha From: Ryan Sleevi rsle...@chromium.org<mailto:rsle...@chromium.org> Sent: Tuesday, October 19, 2021 10:00 PM To: Sasha Tokarev alex...@microsoft.com<mailto:alex...@microsoft.com> Cc: z...@chromium.org<mailto:z...@chromium.org>; rsle...@chromium.org<mailto:rsle...@chromium.org>; blink-dev@chromium.org<mailto:blink-dev@chromium.org>; g...@chromium.org<mailto:g...@chromium.org>; mme...@chromium.org<mailto:mme...@chromium.org>; a...@chromium.org<mailto:a...@chromium.org>; yhir...@chromium.org<mailto:yhir...@chromium.org>; pastarm...@chromium.org<mailto:pastarm...@chromium.org> Subject: Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome On Tue, Oct 19, 2021 at 9:41 PM Sasha Tokarev <alex...@microsoft.com<mailto:alex...@microsoft.com>> wrote: > All of this relates to the questions I was previously asking, because at > least if my understanding is correct, this basically means that as currently > designed, it's not possible to really describe a "standard" flow or > specification. For example, it's not that a particular cookie value will be > present, or a particular header value - the web account provider can return > arbitrary cookies via the WebAccountProviderRetrieveCookiesOperation, and > these should just be passed on to any of the managedUrls. So IdP Foo might > call their cookie "SID", while IdP Bar might call their cookie "Token", and > IdP Baz might use multiple cookies, like "CAW", "DIDC", and "DIDCL". The > browser should just overwrite any cookies it has (e.g. from the browser > cookie jar, or from extensions) with the cookies provided by the Web Account > Provider/IProofOfPossessionCookieInfoManager - right? -True, we tried to make IDP life easier, we wanted them to use any cookies names and semantic. Cookies are a private contract between IDP native component and IDP web service. We never pursued the goal to standardize this aspect. All we can spec for browser SSO on Windows: 1. Windows can have a native IDP component, which installed by the user or built-in in the platform. 2. There is a public API that any web browser can use to pull a list of cookies/headers when navigation happens to an IDP url. 3. Cookie/header names and their semantic is a private contract between an IDP web and its native component on the platform. 4. The web browser should just override cookies with the same names. I hope it clarifies. It really does, and helps understand how this is a very new, very different integration, and does affect some of the understanding of how this fits in the overall Web Platform and interop story (while being mindful of balancing that with our existing threat model)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Frefs%2Fheads%2Fmain%2Fdocs%2Fsecurity%2Ffaq.md%23Why-arent-physically_local-attacks-in-Chromes-threat-model&data=04%7C01%7Calextok%40microsoft.com%7C7f168beea5484620d03c08d994a021c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637704238197171960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pBoyxU8ToNE3maVHBuwpYBJU1SkPwVjYSbqlRpGMtWQ%3D&reserved=0>. One question I had, that I forgot to follow-up on: with these APIs; whether WebAccountProviderRetrieveCookiesOperation or IProofOfPossessionCookieInfoManager::GetCookieInfoForUri, these deal with cookies. You mentioned headers a few times - could you provide any pointers to where the header interactions are / what the APIs? The context here that I'm thinking about is situations like cookie size limits and how these PoP cookies, which we don't know the size apriori, would interact with the browser cookie store. The use of headers mitigates some of that, although with their own complexities, and so it'd be useful to understand what that API shape looks like. -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0381C16F047AB842D2057607A1849%40SN6PR00MB0381.namprd00.prod.outlook.com.
