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<http://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 ):
     *   Detects presence of the SSO cookies, validates them by checking 
signature, and authenticates the user and device.
     *   Validates that the supplied redirect uri is registered for this 
application.
     *   Validates if the resource owner (enterprise admin or user) authorizes 
access to the resource.
     *   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.
     *   Read device identity, and checks the state of device, that reported 
out of band by device management system.
     *   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/SN6PR00MB0381D4A37BC4FBF2CB3927A1A1A39%40SN6PR00MB0381.namprd00.prod.outlook.com.

Reply via email to