I have some questions. - Is the proposal that Chrome detects such a redirect and sends an authentication request to IDP? - Is there at most one IDP for a profile? - How is IDP registered to Chrome?
Thanks, On Fri, Sep 24, 2021 at 6:18 AM 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. >> >> 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. >> 3. *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. >> 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. >> 4. *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. >> 5. *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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc1fb9ba-2951-4d59-aec1-aed2e88fd584n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc1fb9ba-2951-4d59-aec1-aed2e88fd584n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CABihn6G9Vx%3Dya9nHrZ5%3DVCsgEh3gu1eys9xGtrjXL-%2BXU5vcgg%40mail.gmail.com.
