Thanks for the heads up Owen, and thanks Aleksandr for starting the discussion!
I have a lot of questions below, so hopefully it's not overwhelming. This is certainly a very interesting space, and a great chance to modernize things, but also seems like it poses some unique risks. On Thu, Sep 23, 2021 at 5:18 PM Owen Min <[email protected]> wrote: > +people who may be interested in this. > > On Thursday, September 23, 2021 at 12:21:51 PM UTC-4 Sasha Tokarev wrote: > >> Hi all, >> >> I have a proposal to integration with Windows SSO in Chrome. >> >> Currently Windows has ability to join device to cloud identity, like AAD, >> MSA. When a device is joined to a cloud identity provider (IDP), it would >> be great if I’m as a user do not need enter credentials, when I’m using a >> service, which uses IDP where my device is joined to. I’m consented to have >> single sign on (SSO) when I joined the device, and trust IDP to protect my >> identity and do not allow an authorized access. If I do not trust, I should >> not join my device. Additionally, sometimes web resources, that I’m >> accessing to as a user, are owned by organization where I work or study. >> Hence, an organization administrator should be able to manage access to >> such resources based on the quality of my device, e.g., prevent access if >> the device doesn’t make malware scans or doesn’t have latest security >> patches etc. >> >> Edge has this feature built in, in Chrome we must use a special extension >> https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji >> >> While using extension works, the built-in experience is better, as we >> have with Windows Integrated authentication. >> >> In high level it should work like this, if I’m accessing to a resource, >> from a joined device. >> > Is there a public specification for this flow? For example, with existing OS SSO integration, we have a standard set of APIs (GSS-API on Posix platforms, SSPI on Windows, which are both conceptually similar), and a set of specifications for how they interact with Web technologies. I ask, because Negotiate/Kerberos/NTLM integration is already <https://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0690.html> a bit of an outlier <https://datatracker.ietf.org/doc/html/rfc7235#section-5.1.2>, in that it didn't follow the WWW-Authenticate or HTTP semantics. This makes it challenging to support in new protocols (e.g. HTTP/2 or HTTP/3). It seems like, as part of this, having a sense for the specification would be very helpful here. > >> 1. *Resource* (e.g., www.mywork.com) will redirect me for the >> authentication to the cloud identity provider( >> https://login.microsoftonline.com). The request will have a redirect >> URI that IDP will use to return a token. >> 2. *User agent* (Chrome) will detect this navigation and call an OS >> API for producing a crypto-protected SSO cookies, which has device and >> user >> information. This cookie will be appended to the request as a header or >> cookie. >> >> Could you expand on this "header or cookie"? That is, appending cookies from the OS introduces a whole host of complexity considerations, and has to be reasoned about through the network stack. For example, I can imagine issues if we persisted those cookies to disk, since it sounds like the intent is that the cookie value is actually some ephemeral nonce-like/time-bounded thing. This gets messy when merging, and of course, from a privacy angle, when clearing. Having a bit of semantic separation at the transport layer, like a header, seems useful. This is the first I've heard in the context of this feature that a header is viable, and would love to understand and explore that more, because it might address a number of the concerns/considerations. > >> 1. >> 2. *Cloud identity provider* ( https://login.microsoftonline.com ): >> 1. Detects presence of the SSO cookies, validates them by checking >> signature, and authenticates the user and device. >> 2. Validates that the supplied redirect uri is registered for this >> application. >> >> From a threat model standpoint, this makes a lot of sense when OS vendor == Browser vendor == Identity Provider. If you don't trust them, really the whole system collapses. This seems a little more difficult when OS vendor != Browser vendor != Identity Provider, because the responsibilities for privacy and security get divvied up among multiple stakeholders. That is, in the worst case, it seems like a vulnerability in the IDP provider can make the browsing experience unsafe, and the responsibility for that failure will be shared (i.e. users will blame the browser for exposing the feature, and the IDP for failing to secure it appropriately). Do you have any thoughts on how the browser can help make sure that the IdP is acting in the best interests of the user? It sounds like the assumption here is that the user will explicitly accept this risk when they configure the OS for the IdP, is that right? In that model, how can the browser be sure the user made an informed choice, and affirmatively wants the browser to behave this way? Is the scenario here that the browser should just trust the OS, or is a model where the browser also confirms with the user (e.g. via enterprise policy or user consent) part of the thinking? > >> 1. >> 2. Validates if the resource owner (enterprise admin or user) >> authorizes access to the resource. >> 3. Applies consent policy and ask consent if needed, for example >> enterprises, when they own the resource can pre-consent access by their >> employees. Note, It is responsibility of IDP to ensure that only >> authorized >> and consented applications can access users’ identity. >> >> I'm not sure I fully understand this part. Could you share more? Specifically, it's unclear if "applications" here are referring to OS level applications (like the browser), or to web applications (like a relying party). > >> 1. >> 2. Read device identity, and checks the state of device, that >> reported out of band by device management system. >> 3. If all checks are fine, the IDP redirect back to the resource >> with a token. >> 1. *User agent* (Chrome) should not do much, just to make sure it >> will not include SSO headers (as in case of some HTTP Redirects user-agent >> repeats the same headers) and cookies to the resource, to prevent its >> disclosure. >> >> Earlier, you mentioned "header or cookie", and this seems to be describing "SSO headers and cookies". I wasn't sure if it was either/or or both - could you clarify? > >> 1. >> 2. *Resource* gets the token and provides service to the user. >> >> >> >> Note, a malicious web site will not be able to access user identity >> without explicit user consent, and if it is an enterprise account, then it >> should check admin authorization for this application. >> > Just making sure I parse this: the "user consent" being described is from the IdP, right? So the IdP learns about the user's activity - whether malicious or benign websites - and is responsible for helping the user distinguish between those two? And is it correct that when you say "enterprise account", this is in reference to the IdP's notion, not the OS/browser notion? > One may think that if we have SSO, now we need to think about protection >> from malicious web sites. However, this issue is not relevant to SSO, as if >> a user has either MSA or AAD, most likely she or he will enter credentials >> at some moment, and IDP will store persistent cookie. As a result, IDP >> still needs to protect from a malicious web site, that is why all protocols >> that use redirection has special handling for such cases, i.e. the IDP must >> redirect on initially pre-registered for this client redirect URI >> https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2 >> > This is where having a clearer protocol specification will be useful. For example, the OpenID Foundation is working on making it easier for RPs and IdPs to establish relationships, through the FastFed Working Group <https://openid.net/wg/fastfed/>. I recently shared some concerns <http://lists.openid.net/pipermail/openid-specs-fastfed/Week-of-Mon-20210823/000358.html> with some of the current draft's assumptions, and how they might facilitate malicious RPs or impersonating IdPs. It'd be useful to have a broader sense of the protocol at play here, since it sounds like the core goal is for the browser to trust the IdP, on the basis that the OS is configured to trust the IdP, and that both the user intentionally configured the OS, and that the user explicitly confirmed with the IdP. I'm not trying to suggest anything nefarious here, but trying to make sure we've got a good understanding of the assumptions we make. These may be entirely reasonable assumptions (e.g. the OS threat model is explicitly addressed as out of scope <https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/faq.md#Why-arent-physically_local-attacks-in-Chromes-threat-model> in the security FAQ), but it may also reveal complicated interactions that could limit the evolution of new protocols (e.g. as Negotiate/Kerberos/NTLM did re: HTTP/2 and HTTP/3) or present challenges to some of the work regarding privacy sandbox <https://www.chromium.org/Home/chromium-privacy/privacy-sandbox>. The more documentation you can provide about the protocol interactions, the easier it is to evaluate those and be confident the risks are mitigated. > SSO itself reduces number of prompts, OS cookies are hardware crypto >> protected and short-lived, while protection of web-cookies is lower. >> Integration with OS SSO not just a convenience feature but increases users’ >> security. >> > Absolutely, there's a lot of good stuff that can be done. Ideally, however, we can pursue that through standards, such as WebAuthN, to help ensure users are secure regardless of the OS or IdP. Obviously, we still support protocols like Kerberos and NTLM, so it's not that OS integration doesn't make any sense - just that it comes with its own set of risks and tradeoffs. One way of thinking about this is that bringing in some of these high-level protocols from the OS - from any OS - is a bit like adding third-party libraries <https://chromium.googlesource.com/chromium/src.git/+/HEAD/docs/adding_to_third_party.md>, since it extends the attack surface of the browser. We obviously add 3P libraries all the time, so it's not that I'm saying we shouldn't do this at all, but it's good to get a sense of how it will work, both technically and with web standards, to evaluate the risk. One last question, if I haven't overwhelmed you with questions already - if there are protocol concerns (e.g. the headers vs cookies discussion), does the fact that it sounds like the IdP and the OS are both same-party mean that there may be a possibility of adjusting the protocol to better fit with the Web Platform? I realize that's probably a huge request, and it may be the answer is "No, none of this can change" - but I'm asking now, mostly to understand "What do we do if the new protocol has similar spec-violating issues like Negotiate/Kerberos/NTLM did", and what the options might be to prevent or address that. > -- 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/CACvaWvYsFnN52%2B4g3SfwUAzW0PGqk%2B%3DZYxCzJ%3DQvVYQaJ7tc%3DA%40mail.gmail.com.
