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

[Matt Menke]

Thanks for the details, Sasha!  Please don't feel like you need to answer
my questions while on vacation - there's no rush here.

Enjoy your vacation!

On Sat, Sep 25, 2021 at 9:22 PM Sasha Tokarev  wrote:

> Hi Matt,
>
>
>
> Disclaimer: I’m at vacation my responses may delay.
>
>
>
> *> 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"?*
>
>
>
> There are many ways of joining devices, many of them looks like domain
> joining, and requires admin’s action and explicit user action. Home user
> also either go via explicit action and consent which include web SSO:
>
> [image: Graphical user interface, text, application Description
> automatically generated]
>

Thanks!  So this is a per-local-app permission, that can also be granted to
all apps?  My main concerns, in terms of privacy (not security issues) here
are:

1)  Home user using a Microsoft account on their personal device
unexpectedly gets logged in.  If the user has to give explicit permission
to Chrome or all apps (apart from just using a Microsoft account), as it
sounds like is the case, I'm much less concerned about this.  I'd still be
more comfortable if Chrome-side integration is disabled by default, though
the settings folk may not think it's worth a new setting.
2)  An enterprise uses corp Microsoft accounts, but doesn't want to use
Microsoft as an IDP.  It may not want this information to be sent to
Microsoft.  Admittedly, I'm not sure how much of a concern this is, if
Microsoft is managing their accounts in the first place.  Note that I'd be
concerned about this happening for non-Microsoft managed accounts here,
too, just think it's less likely for it to be possible to accidentally
happen for non-Microsoft accounts.  Sounds like this does need explicit
opt-in even with Microsoft managed accounts, so sounds like this isn't at
all an issue.
3)  A bit less of a concern, but a person using their home account on a
corp device (not uncommon, though not generally a great idea), gets their
personal, non-corp managed account, sent to the IDP, inheriting the fact
that IDP is enabled on the device.  It could either be using the corp IDP
configuration, or the IDP configuration associated with the domain of their
home account - both seem problematic to me.
4)  Enterprise intends to use the feature, but accidentally leaks this
information to a 3P. bouncing through the IDP.  It sounds like there's
server-side configuration to prevent this, and given that the feature has
to be explicitly enabled on the OS, they've already indicated that they
trust their IDP.

 *> Would this be enabled by default (for enterprise users only)? *
>
>
>
> It is like domain join, when you join device to domain you expect SSO.
> Given that there is explicit user or admin action, and consent, which
> includes web SSO, it should be enabled by default both for consumers and
> enterprise users, like it is enabled in Edge. Additional flags will only
> complicate deployment and doesn’t bring extra protection, users will have
> to remember about the extra flag. It decreases effectiveness of the
> feature.
>
>
>
> We do not ask to deploy extra flags to enable Windows Integrated Auth,
> once you joined to the domain you got it, this is a new versions of Windows
> Integrated Authentication.
>
>
>
> *> Also, what about incognito? *
>
>
>
> In incognito it must be OFF by default, to protect user and organization,
> but it is OK, to have a settings controllable by admin to make it on.
>
>
>
> *> 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
> 

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

['Sasha Tokarev' via blink-dev]

Hi Matt,

Disclaimer: I'm at vacation my responses may delay.

> 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"?

There are many ways of joining devices, many of them looks like domain joining, 
and requires admin's action and explicit user action. Home user also either go 
via explicit action and consent which include web SSO:
[Graphical user interface, text, application  Description automatically 
generated]

> Would this be enabled by default (for enterprise users only)?

It is like domain join, when you join device to domain you expect SSO. Given 
that there is explicit user or admin action, and consent, which includes web 
SSO, it should be enabled by default both for consumers and enterprise users, 
like it is enabled in Edge. Additional flags will only complicate deployment 
and doesn't bring extra protection, users will have to remember about the extra 
flag. It decreases effectiveness of the feature.

We do not ask to deploy extra flags to enable Windows Integrated Auth, once you 
joined to the domain you got it, this is a new versions of Windows Integrated 
Authentication.

> Also, what about incognito?

In incognito it must be OFF by default, to protect user and organization, but 
it is OK, to have a settings controllable by admin to make it on.

> 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?

I'm not sure I fully understand the attack here. Evil.com will have to use 
mywork.com's redirect URI, it means that token 
(authentication artifact) will be delivered to https://www.mywork.com not to 
evil.com. Overall, these kinds of threats covered by federation protocols OIDC, 
OAuth, SAML etc. IDPs exist in the modern world (Facebook, Google, AAD, MSA) 
they have to be protected from all kinds of threats, as they authenticate the 
user and redirect the token. All these IDPs produce a cookie for themselves to 
avoid useless re-auth. This proposal only manages the way of more secure 
delivering those cookies from native component in OS, which must be implemented 
by IDPs vendors, to IDPs web site. This proposal doesn't change protocols how 
an IDP talks with web applications (aka resources, aka target resources, aka 
relying parties). All threats and mitigation applied to existing protocols.

> 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?

No, all navigations. It is a cookie by nature, it must follow all cookie rules. 
If XHR-web request should append a cookies, then we need append this cookie. 
The difference between this cookie and regular cookie is regular cookie is not 
protected, an attacker can steal it and use on a different device. This cookie 
is protected. Attacker can steal it but it will be expired very fast.

> 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?

I think it is easier to answer this question is to describe what cookie is. 
Please, note, format of the cookie is something internal between IDP native 
component and IDP web services.  Microsoft's cookie is JWT-blob that contains 
PRT,
 nonce, and 

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

[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

[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