[blink-dev] Re: Native support of Windows SSO in Chrome

2021-09-25 Thread Matt Menke
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  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
>> 

[blink-dev] Re: Native support of Windows SSO in Chrome

2021-09-25 Thread Ryan Sleevi
Thanks for the heads up Owen, and thanks Aleksandr for starting the
discussion!

I have a lot of questions below, so hopefully it's not overwhelming. This
is certainly a very interesting space, and a great chance to modernize
things, but also seems like it poses some unique risks.

On Thu, Sep 23, 2021 at 5:18 PM Owen Min  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.
>>
>
Is there a public specification for this flow? For example, with existing
OS SSO integration, we have a standard set of APIs (GSS-API on Posix
platforms, SSPI on Windows, which are both conceptually similar), and a set
of specifications for how they interact with Web technologies.

I ask, because Negotiate/Kerberos/NTLM integration is already
 a bit
of an outlier ,
in that it didn't follow the WWW-Authenticate or HTTP semantics. This makes
it challenging to support in new protocols (e.g. HTTP/2 or HTTP/3). It
seems like, as part of this, having a sense for the specification would be
very helpful here.


>
>>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.
>>
>> Could you expand on this "header or cookie"? That is, appending cookies
from the OS introduces a whole host of complexity considerations, and has
to be reasoned about through the network stack. For example, I can imagine
issues if we persisted those cookies to disk, since it sounds like the
intent is that the cookie value is actually some ephemeral
nonce-like/time-bounded thing. This gets messy when merging, and of course,
from a privacy angle, when clearing. Having a bit of semantic separation at
the transport layer, like a header, seems useful. This is the first I've
heard in the context of this feature that a header is viable, and would
love to understand and explore that more, because it might address a number
of the concerns/considerations.


>
>>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.
>>   2. Validates that the supplied redirect uri is registered for this
>>   application.
>>
>> From a threat model standpoint, this makes a lot of sense when OS vendor
== Browser vendor == Identity Provider. If you don't trust them, really the
whole system collapses.

This seems a little more difficult when OS vendor != Browser vendor !=
Identity Provider, because the responsibilities for privacy and security
get divvied up among multiple stakeholders.

That is, in the worst case, it seems like a vulnerability in the IDP
provider can make the browsing experience unsafe, and the responsibility
for that failure will be shared (i.e. users will blame the browser for
exposing the feature, and the IDP for failing to secure it appropriately).
Do you have any thoughts on how the browser can help make sure that the IdP
is acting in the best interests of the user?

It sounds like the assumption here is that the user will explicitly accept
this risk when they 

RE: [EXTERNAL] Re: [blink-dev] Re: Native support of Windows SSO in Chrome

2021-09-24 Thread 'Sasha Tokarev' via blink-dev
As @Owen Min<mailto:z...@chromium.org> said, IDP registered in OS.

 - Is there at most one IDP for a profile? /
In one Windows logon session there can be multiple IDP urls associated with 
different clouds, global cloud, China cloud, and also consumer cloud.

Per Profile there can be multiple IDPs.

Thank you,
Sasha

From: Owen Min 
Sent: Friday, September 24, 2021 3:24 PM
To: Yutaka Hirano 
Cc: blink-dev ; Sasha Tokarev ; 
Greg Thompson ; Matt Menke ; Ryan 
Sleevi ; Adam Langley 
Subject: [EXTERNAL] Re: [blink-dev] Re: Native support of Windows SSO in Chrome

You don't often get email from z...@chromium.org<mailto:z...@chromium.org>. 
Learn why this is important<http://aka.ms/LearnAboutSenderIdentification>
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 
mailto:yhir...@google.com>> 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogin.microsoftonline.com%2F=04%7C01%7Calextok%40microsoft.com%7C556f27a84dc74464e78e08d97faa0c96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681190657478260%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=cmRqASVehjSxUqMOY27cAw3OxcL1mLyzrPmoYEuOMcw%3D=0>)
 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium-review.googlesource.com%2Fc%2Fchromium%2Fsrc%2F%2B%2F3147471%2F10%2Fcontent%2Fbrowser%2Fnet%2Fcloud_ap%2Fcloud_ap_platform_win.cc%23399=04%7C01%7Calextok%40microsoft.com%7C556f27a84dc74464e78e08d97faa0c96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681190657488255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=yRSdmucNgrhggODLeKX3IvQvtfuvo0ZNJsorc1uPF4U%3D=0>)
 and cookies from the OS.

Thanks,

On Fri, Sep 24, 2021 at 6:18 AM Owen Min 
mailto: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. 
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchrome.google.com%2Fwebstore%2Fdetail%2Fwindows-10-accounts%2Fppnbnpeolgkicgegkbkbjmhlideopiji=04%7C01%7Calextok%40microsoft.com%7C556f27a84dc74464e78e08d97faa0c96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681190657498247%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=dW13qaXD0Rc0llwQHlUR4PDrxNjZkdf2oZ%2FmuJFMgvo%3D=0>
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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mywork.com%2F=04%7C01%7Calextok%40microsoft.com%7C556f27a84dc74464e78e08d97faa0c96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681190657498247%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=6rqBLE8dQhorw2dB3YWSYYf91aDEcoq6XlB%2BwfXsN1A%3D=0>)
 will redirect me for the authentication to the cloud identity 
provider(https://login.microsoftonline.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogin.microsoftonline.com%2F=04%7C01%7Calextok%40microsoft.com%7C556f27a84dc74464e78e08d97faa0c96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681190657508241%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD

Re: [blink-dev] Re: Native support of Windows SSO in Chrome

2021-09-24 Thread Owen Min
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  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
)
and cookies from the OS.

>
> Thanks,
>
> On Fri, Sep 24, 2021 at 6:18 AM Owen Min  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 

Re: [blink-dev] Re: Native support of Windows SSO in Chrome

2021-09-23 Thread 'Yutaka Hirano' via blink-dev
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  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 blink-dev+unsubscr...@chromium.org.
> 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
> 

[blink-dev] Re: Native support of Windows SSO in Chrome

2021-09-23 Thread Owen Min
+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 blink-dev+unsubscr...@chromium.org.
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.