+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.
