Would this be enabled by default (for enterprise users only)? This puts a lot of faith in the IDP, and I'd be more comfortable with a group policy opt-in, ideally either listing the IDP explicitly as trusted, or listing what sites it's trusted to authenticate to. This may be a bit redundant with OS configuration, but this does let the IDP coordinate with sites to bypass browser privacy protections, which is rather powerful, particularly as we work towards a more privacy-focused web.
Also, what about incognito? It's unclear if the OS calls to get tokens to send to the IDP affect local state, but even if they don't, this allows incognito identity to be joined to non-incognito identity - yes, for nominally trusted sites, though I suspect users wouldn't expect automatic login in incognito mode. On Thu, Sep 23, 2021 at 5:18 PM Owen Min <z...@chromium.org> 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. >> > What's the flow to join a cloud identity here? What are the permission prompts like? I assume that home users who use generic home user Microsoft accounts (as I believe encouraged during Windows install/configuration) aren't assumed to be granting this permission, though it could reasonably be described as a "device joined to cloud identity"? > 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. >> >> 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. >> >> So this means evil.com could redirect to https://login.microsoftonline.com/, and tell it to log in using the IDP to https://www.mywork.com, by providing a redirect URI there? Or is the referrer to the IDP validated in some way? > >> 1. >> 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. >> >> I believe the initial proposed CL I saw wiring this up added the cookies to all requests to the magic URL. Does this mean that only main frame navigations need these additional cookies? >> 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. >> >> Is there some other communication behind the scene between the OS and the IDP here to authenticate the device? Or is this just a matter of encoding data in the request? > >> 1. >> 2. Validates that the supplied redirect uri is registered for this >> application. >> 3. Validates if the resource owner (enterprise admin or user) >> authorizes access to the resource. >> 4. 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. >> 5. Read device identity, and checks the state of device, that >> reported out of band by device management system. >> 6. 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. >> 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. 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 >> >> 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. >> >> >> >> Thank you, >> Aleksandr >> > -- 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/CAEK7mvqk36EzPjU-QOjRsHtk4u%3DyYZKi1MKycip7rq8xmq6pJg%40mail.gmail.com.
