Answer inline. Sasha and Greg, feel free to correct me or add more things if you want.
On Fri, Sep 24, 2021 at 1:27 AM Yutaka Hirano <[email protected]> wrote: > I have some questions. > > - Is the proposal that Chrome detects such a redirect and sends an > authentication request to IDP? > Browser detects the access of IDP URL(https://login.microsoftonline.com) and appends a cookie which gets from the OS to that request. > - Is there at most one IDP for a profile? / > - How is IDP registered to Chrome? > IDPs are registered with the OS. And the browser gets both IDP urls (see CloudApPlatformWin::ReadOrigins <https://chromium-review.googlesource.com/c/chromium/src/+/3147471/10/content/browser/net/cloud_ap/cloud_ap_platform_win.cc#399>) and cookies from the OS. > > 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/CAN%2BknvXK6x5a8Ujgghj0Er0JKES2mh-iakmRq5-6TmvjC9%2B2bA%40mail.gmail.com.
