Native support of Windows SSO in Chrome
Sasha Tokarev
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.
- 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.
- 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.
- 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.
- 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.
- 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
Owen Min
Yutaka Hirano
--
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+...@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.
Owen Min
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?
Sasha Tokarev
As @Owen Min 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 <zm...@chromium.org>
Sent: Friday, September 24, 2021 3:24 PM
To: Yutaka Hirano <yhi...@google.com>
Cc: blink-dev <blin...@chromium.org>; Sasha Tokarev <ale...@microsoft.com>; Greg Thompson <g...@chromium.org>; Matt Menke <mme...@chromium.org>; Ryan Sleevi <rsl...@chromium.org>; Adam Langley <a...@chromium.org>
Subject: [EXTERNAL] Re: [blink-dev] Re: Native support of Windows SSO in Chrome
|
You don't often get email from zm...@chromium.org. Learn why this is important |
Ryan Sleevi
+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.
- 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.
- 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.
- 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.
- 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.
- 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.
Matt Menke
+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.
- 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.
- 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.
- Cloud identity provider ( https://login.microsoftonline.com ):
- Detects presence of the SSO cookies, validates them by checking signature, and authenticates the user and device.
Sasha Tokarev
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:
> 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 signature. The PRT contains deviceid, userid and the key hash. The key for the signature is in a hardware chip, e.g., TPM:
{
ctx: "HfRmDwiULBY5mDyUxd8\/RQV2xs72B55H",
alg: "HS256"
}.
{
request_nonce: "AQABAAAAA…. < used to make sure that issuer still has access to the hardware key >",
refresh_token: "AQABAAAAAAA….< an encrypted by IDP blob that contains deviceid, userid, keyHash >",
iat: 1597885901
}.
[signature]
When such cookie arrived to IDP, we check nonce and signature. It gives us assurance PRT comes from the same device as it was originally created. Hence, we can trust device and user info inside PRT. A browser doesn’t create PRT, PRT is created and updated:
- During Windows logon
- Application logon (if user has added account), e.g., when Outlook accessing Exchange.
Browser just reads PRT-cookie.
Thank you,
Aleksandr
Matt Menke
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:
> 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.
Sasha Tokarev
Hi Ryan,
Thank you for your email.
One logistics aspect: I don’t know the culture in this DL is it ok to merge 2 different forks in one or keep forks independent. I decided to keep fork independent as they were not created by me, but expect @Owen or somebody help me with this.
> Is there a public specification for this flow?
Yes and no 😊 overall there are a lot of protocols that controls relationships between IDP and web-application (aka resource, aka target-resource, aka application). These protocols are public and are not subject to this proposal. In all those protocols when request reaches to IDP, job of IDP to authenticate the user. As I said in a different thread the IDP, including Google, will store a cookie to prevent re-auth. In scope of this proposal is how IDP will pull a cookie from a native component. It is a relationship between IDP and IDP’s native component that is part of operation system.
On Windows we have a framework WebAccountManager (WAM) that allow Google to add their own authentication plugin. If Google ever decide to do it, then users will be able to read email from Outlook or modify Google docs in Word. We wish Google to add this plugin, and we can help with it. Here is how the WAM plugin relates to browser SSO. Assume Google creates the plugin.
- User opens Word, and enters his/her Gmail account to access Google Drive, in Google WAM plugin (relationship between User and Google)
- Google WAM Plugin asks “Do you want add this account to Windows and able to access Google services from everywhere other applications and web?”
- User clicks yes.
- Google WAM plugin creates SSO artifact, and creates account in the system, user can control it from Settings.
- User launches Outlook and Outlooks and can read Gmail from Outlook.
- User opens a web browser Edge, IE, FireFox, Chrome navigates to gmail.com.
- Gmail.com navigates to accounts.google.com
- Web browser sees that accounts.google.com in a registered Url list.
- Web browser calls api to pull the cookies GetCookieForUri.
- Web browser appends these cookies to the request to accounts.google.com
- Account.google.com validates cookies and proof of possession authenticates the user and redirect back to Gmail.com with token.
- Gmail.com displays user’s emails.
Please, note, only 6.b-d is in scope of the current ask.
I skipped a lot of details, but this is a high-level end to end flow, which describes it is not about Microsoft, it about relationship application and browser SSO. Unfortunately, Google decided not to implement Google WAM plugin (I don’t know why 😊), while the plugin could make Google services closer to Windows users. Only Microsoft (MSA and AAD) implemented their plugins.
Why it is not a standard auth protocol?
Because only few vendors in the world supposed to implement it Facebook, Google, Amazon, Microsoft, and only one implemented end to end. If Google want to participate from IDP side, we can discuss how to make and official protocol from this.
> This seems a little more difficult when OS vendor != Browser vendor != Identity Provider,
I hope by this moment it is clear that this is relationship between Native IDP component that part of OS, and web part of IDP, and browser. Expectation is: vendor of native IDP component in OS == vendor of IDP in web != Browser vendor.
There is no expectation that someone install a web server which will authenticate by pulling cookies, those cookies visible only to IDP web site, but we can discuss how to officially spec it.
> Could you expand on this "header or cookie"?
By default, we treat it as cookie. It should behave like cookie. Logic is following, if there is no WAM plugin, account.google.com will store a cookie. “cookie” that we return from that API is more secure than regular cookie, as it is TPM bound. Basically, when you call that API you pull a short lived, tpm bound, sso-cookie - it is more stronger than regular cookie.
We switched to headers, because when we have multiple accounts on the system, we hit cookie size limit and proxy blocks requests, or removes cookies.
However, by nature it is a cookies, and all cookies rules must apply, for example browser MUST NOT append this header to a different URL to avoid security incidents.
> I can imagine issues if we persisted those cookies to disk
It is ok to persist them on the disk. You store regular cookies from IDP on the disk. This stuff more secure. They protected from stealing. It is IDP native component responsibility to take care of this.
> 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).
It is a case right now. As I’ve said earlier IDPs already store cookies and “a vulnerability in the IDP provider can make the browsing experience unsafe”. This proposal doesn’t change anything in this aspect. Only adds new place for storing/reading cookie, the native component of IDP, and make cookie more secure.
> 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?
This is a more generic question, that we can discuss, but as I’ve said earlier with this proposal, we don’t change anything in this aspect. Hence, we will just diverge the conversation. I think it is better to discuss this topic with OIDC or OAuth group.
> It sounds like the assumption here is that the user will explicitly accept this risk when they configure the OS for the IdP, is that right?
Yes
> In that model, how can the browser be sure the user made an informed choice, and affirmatively wants the browser to behave this way?
How today, the browser is sure that the user made an informative choice by authenticating in accounts.gmail.com and consented to persist the cookie?
> Is the scenario here that the browser should just trust the OS, or is a model where the browser also confirms with the user (e.g. via enterprise policy or user consent) part of the thinking?
Browser should just trust OS, the same as it trusts when it calls ReadFile windows API to read cookie file. How a browser sure that we Microsoft underneath on driver level read right bits, and not feed cookie from WAM plugin? I think OS and browser share responsibility to do right thing. We, OS, cannot insert a hook in read file api to give some data that will be useful for us, because when people will discover it, and it will be discovered, we will be in very bad situation. Overall, from my understanding of the software development, the browser has no option “Do not trust OS” OS can do everything in the browser memory space.
We should trust each other 😊.
The same statement applies to IDPs, browser should trust IDPs, if an IDP makes a mistake or misbehaves users will punish them by dollar.
- 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.
I'm not sure I fully understand this part. Could you share more?
Specifically, it's unclear if "applications" here are referring to OS level applications (like the browser), or to web applications (like a relying party).
“application” here is “web-applications” (==resource).
This part about consent. Overall, consent is a big topic, and usually consent starts from who owns the resources. If it is a document on my personal OneDrive or Google drive, then I’m the owner. If it is on my corporate OneDrive or SharePoint, then my company is the owner. The owner decides who can access, and which application can access. Also, in the enterprise world the consent story even more complex, employees should not use some random applications without pre-authorization from management.
All those relationships managed by IDP and I don’t see how browser can help here, as the browser doesn’t know who the owner is, what was pre-authorized for accessing without consent, what was forbidden, etc. The browser can only destruct by very questionable prompts.
> Earlier, you mentioned "header or cookie", and this seems to be describing "SSO headers and cookies". I wasn't sure if it was either/or or both - could you clarify?
In some case we issue cookies, in some cases header, but both header and cookies should behave like cookie. It is only question of size limitation on cookies.
> Just making sure I parse this: the "user consent" being described is from the IdP, right? So the IdP learns about the user's activity - whether malicious or benign websites - and is responsible for helping the user distinguish between those two?
Right, IDP must not allow a malicious web site to access data without authorization.
> And is it correct that when you say “enterprise account”, this is in reference to the IdP’s notion, not the OS/browser notion?
Here it is user account in IDP notion. IDP can serve enterprise needs, and personal/consumer accounts needs. Azure Active Directory is IDP for enterprises (aka organizational accounts, aka work or school accounts) it is Azure AD responsibility to know who can access what, and Azure AD has huge portal which allows amdin to control its resources. While Google Account, or Microsoft Account, or Facebook is usually mange consumers identity.
In one logon session in OS, you can have multiple enterprise accounts and multiple personal/consumers accounts. Additionally, you can be logged in using your personal account via operation system logon, or using your enterprise account. So, “enterprise account” can be applied to windows logon as well. However, in that context, I meant “if there was enterprise account delivered via cookie then consent logic is not sufficient we need to take into consideration if admin allowed this relationship and other enterprise policies”.
> This is where having a clearer protocol specification will be useful.
Once you read everything, and digest, could you, please, advice what part do you want to spec? I see that we can formally document only this:
- Browser reads list of urls from OS
- If navigation happens for an interesting URL, then browser should call API to get cookies or headers.
- Browser appends cookies or headers to the request.
- If it is header it should appended in all places where cookies are appended, on any navigation to an interesting URL.
Is that what matches your expectation we should spec?
> if there are protocol concerns (e.g. the headers vs cookies discussion), does the fact that it sounds like the IdP and the OS are both same-party mean that there may be a possibility of adjusting the protocol to better fit with the Web Platform?
I’m fine to jump and building new protocol, but by the time we adjust OS and release new protocol, Chrome users will be impacted, as they will be blocked by device conditional access. Right now, Chrome user experience degraded experience compared to Edge and Firefox, in some cases they even blocked. Release a new protocol will take us a year or more, and most likely will be in a new version of Windows (+ 2 years when majority population will be on that version).
Thank you,
Aleksandr
From: Ryan Sleevi <rsl...@chromium.org>
Sent: Saturday, September 25, 2021 11:17 AM
To: Owen Min <zm...@chromium.org>
Cc: blink-dev <blin...@chromium.org>; Sasha Tokarev <ale...@microsoft.com>; Greg Thompson <g...@chromium.org>; Matt Menke <mme...@chromium.org>; Ryan Sleevi <rsl...@chromium.org>; Adam Langley <a...@chromium.org>; Yutaka Hirano <yhi...@chromium.org>
Subject: [EXTERNAL] Re: Native support of Windows SSO in Chrome
Thanks for the heads up Owen, and thanks Aleksandr for starting the discussion!
Ryan Sleevi
Owen Min
Sasha Tokarev
Hi all,
I came back from vacation and happy to continue our conversation.
Ryan, your understanding is mostly correct, except some small details.
You are right, WAM is a generic extensibility framework, where any IDP (Okta, Google, Facebook) can implement a plugin (WAM Plugin) and provide SSO for native applications (application SSO). A WAM plugin primarily is user component. Only 1st party plugins can produce a system wide token – the tokens that represents device, without user (device only token). Just FYI, a token for a public client in Microsoft eco system can represent:
- User
- User + device
- Device only
However, device only token is not relevant to our conversation, it is application SSO niche scenario. Additionally, 1st party Microsoft IDPs know how to communicate with Windows Logon and share their state with Windows Logon.
Primary Refresh Token (PRT) and Azure AD - Azure Active Directory | Microsoft Docs
So, when the user logs into Windows, we produce a device bound SSO artifact, which we can use to issue access tokens or browser SSO cookie. Any application, including 3rd party ones, can call WAM to get access token, and we will use the SSO artifact to request the access token. In this model, the token is not embedded deep in the network stack like in old protocols, tokens are not transparent for native applications, it is the application responsibility to deliver the token to the service. There is also no requirement to use OAuth as a protocol for a WAM plugin, the protocol can be anything, because native applications call WAM’s GetToken* APIs to get tokens, and don’t care about protocols.
To summarize WAM is component that responsible both for application SSO and browser SSO. 1st party plugins talk to Windows Logon, but 3rd party plugins cannot do it. All application can use WAM to get access tokens.
Note, it is also not mandatory for a WAM plugin to have a integration with Windows logon. WAM plugins can produce the SSO artifact, when a native application request and access token, and it happens in some cases.
I hope application SSO is clear at this point. For browser SSO story is a little bit different. For web applications we do not have such GetToken API, and the framework helps to build SSO cookies from the SSO artifact that was obtained/refreshed by the WAM Plugin or Windows logon. As a result, the system allows to securely share SSO state between native and web applications (reduce the prompts).
As I’ve noted earlier:
- A web application navigates to an IDP web service for authentication.
- The IDP web service authenticates the user.
- The IDP web service redirects back to the application with a token.
Note, protocol here is not mandatory OAuth as well, but for Microsoft OAuth is the primary one.
In the original version, the IDP web service supposed to pull cookies from WAM (during authentication step #2), that why we introduced and implemented WebAccountProviderRetrieveCookiesOperation. However, after monitoring we understood that this part doesn’t work good enough, and we switched implementation on the old IProofOfPossessionCookieInfoManager::GetCookieInfoForUri, which is completely different from WebAccountProviderRetrieveCookiesOperation. At the moment of switching on GetCookieInfoForUri API, we knew that big players are not going to implement WAM plugins in the nearest future (it was 2015), that is why we didn’t wire GetCookieInfoForUri with 3rd party plugins, only 1st parties work with this API. However, if any big player integrates with WAM, we will wire GetCookieInfoForUri with the rest of framework, but even in 2021 no 3rd party IDPs are integrated with WAM (it was a resourcing decision for us, we more than happy to collaborate on this aspect).
GetCookieInfoForUri is a pure native and doesn’t call any managed code. GetCookieInfoForUri API is highly performant. It has 0 cost for non-IDPs URLs, and has some hardware crypto for IDP URLs, but number of navigations to IDP urls is negligible compared to all navigation, so hardware crypto should not impact the performance.
With respect to this:
> The WAM remarks are all .NET managed code, and it sounds like this COM interface provides a handy abstraction around that logic.
There are 0 plugins for now, which uses .NET. All code is native C++. I think confusion comes from the fact that new Windows API (WinRT/UWP) has perfect projection to C++, C#, JS, and you can write on any language. You can switch the language from menu in right corner of the page:
However, as you probably noted — it is not important how WAM plugin is implemented, it is important how GetCookieInfoForUri is implemented, and we implemented it with keeping performance in mind.
> All of this relates to the questions I was previously asking, because at least if my understanding is correct, this basically means that as currently designed, it's not possible to really describe a "standard" flow or specification. For example, it's not that a particular cookie value will be present, or a particular header value - the web account provider can return arbitrary cookies via the WebAccountProviderRetrieveCookiesOperation, and these should just be passed on to any of the managedUrls. So IdP Foo might call their cookie "SID", while IdP Bar might call their cookie "Token", and IdP Baz might use multiple cookies, like "CAW", "DIDC", and "DIDCL". The browser should just overwrite any cookies it has (e.g. from the browser cookie jar, or from extensions) with the cookies provided by the Web Account Provider/IProofOfPossessionCookieInfoManager - right?
-True, we tried to make IDP life easier, we wanted them to use any cookies names and semantic. Cookies are a private contract between IDP native component and IDP web service. We never pursued the goal to standardize this aspect.
All we can spec for browser SSO on Windows:
- Windows can have a native IDP component, which installed by the user or built-in in the platform.
- There is a public API that any web browser can use to pull a list of cookies/headers when navigation happens to an IDP url.
- Cookie/header names and their semantic is a private contract between an IDP web and its native component on the platform.
- The web browser should just override cookies with the same names.
I hope it clarifies.
Thank you,
Aleksandr
Ryan Sleevi
> All of this relates to the questions I was previously asking, because at least if my understanding is correct, this basically means that as currently designed, it's not possible to really describe a "standard" flow or specification. For example, it's not that a particular cookie value will be present, or a particular header value - the web account provider can return arbitrary cookies via the WebAccountProviderRetrieveCookiesOperation, and these should just be passed on to any of the managedUrls. So IdP Foo might call their cookie "SID", while IdP Bar might call their cookie "Token", and IdP Baz might use multiple cookies, like "CAW", "DIDC", and "DIDCL". The browser should just overwrite any cookies it has (e.g. from the browser cookie jar, or from extensions) with the cookies provided by the Web Account Provider/IProofOfPossessionCookieInfoManager - right?
-True, we tried to make IDP life easier, we wanted them to use any cookies names and semantic. Cookies are a private contract between IDP native component and IDP web service. We never pursued the goal to standardize this aspect.
All we can spec for browser SSO on Windows:
- Windows can have a native IDP component, which installed by the user or built-in in the platform.
- There is a public API that any web browser can use to pull a list of cookies/headers when navigation happens to an IDP url.
- Cookie/header names and their semantic is a private contract between an IDP web and its native component on the platform.
- The web browser should just override cookies with the same names.
I hope it clarifies.
Sasha Tokarev
Hi all,
You are correct with respect to cookie size limit. Because there is a 4k limit for all cookies, when we introduced multiple accounts, we hit this limit and some proxies started to block our requests. That why we changed our cookies to headers.
Right now, IProofOfPossessionCookieInfoManager::GetCookieInfoForUri can return either a list of cookies or a list of headers.
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.21329
x-ms-DeviceCredential: eyJhbGciOiJSUzI1NiIsICJ0eXAiOiJKV1QiLCAieDVjI…
x-ms-RefreshTokenCredential: eyJrZGZfdmVyIjoyLCJjdHgiOiIyckJrVzcxQzFCSjg1Q1ZSSWtlWmRmYklReW9…
x-ms-DeviceCredential1: eyJhbGciOiJSUzI1NiIsICJ0eXAiOiJKV1QiLCAieDVjI…
x-ms-RefreshTokenCredential1: eyJrZGZfdmVyIjoyLCJjdHgiOiIyckJrVzcxQzFCSjg1Q1ZSSWtlWmRmYklReW9…
if the name of the cookie starts from x-ms- then this cookie should be added as a header, otherwise as a cookie, please, see attached example:
if (_wcsnicmp(tokens[i].name, L"x-ms-", _countof(L"x-ms-")) == 0)
{
std::wcout << "Add as a header: \n\t" << tokens[i].name << ": " << tokens[i].data << std::endl;
}
else
{
std::wcout << "Add as a cookie: \n\t" << tokens[i].name << "==" << tokens[i].data << tokens[i].p3pHeader << std::endl;
std::wcout << "\tP3P: " << tokens[i].p3pHeader << std::endl;
std::wcout << "\tdwFlags for InternetSetCookieEx: "<< std::hex << tokens[i].flags<< std::endl;
// https://docs.microsoft.com/en-us/windows/win32/api/wininet/nf-wininet-internetsetcookieexa
}
Thank you,
Sasha
From: Ryan Sleevi
rsl...@chromium.org
Sent: Tuesday, October 19, 2021 10:00 PM
To: Sasha Tokarev ale...@microsoft.com
Cc: zm...@chromium.org;
rsl...@chromium.org; blin...@chromium.org;
g...@chromium.org;
mme...@chromium.org; a...@chromium.org;
yhi...@chromium.org; pasta...@chromium.org
Subject: Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome
Ryan Sleevi
Sasha Tokarev
Hy Ryan,
Sorry for the delay and thank you for open discussion.
I would like to start from the simple point:
> it means clearing cookies in Chrome may no longer clear cookies, because these IDP APIs may hold on to them.
I think it is true for any authentication that part of Chrome, like Digest, Client TLS, Windows Integrated (NTLMv2, Kerberos) etc. I think the cookie cleanup will not prevent a web site that performs Windows Integrated authentication to know who you are. In this aspect it is a new form of Windows Integrated authentication, but more secure. I think Chrome implements Windows Integrated authentication as well as other forms of authentication, and not really concerned about it. From the other hand, a web app that integrated with IDP will lost its cookies and state on the cookie cleanup, and will have to start authentication process again, redirect to IDP, account consent if needed, etc. We also can discuss how we can support different browser profiles in this area.
One part that I haven’t covered yet, that those headers/cookies have device id inside, and admins have tools to enable access to their resources based on the state of device. For example, they can allow to access to SharePoint, only if a user’s device is compliant (has the latest updates and satisfy other company’s requirements). Most Microsoft customers enjoy using conditional access policies to protect their cloud resources. These policies are widely used because they allow granular control of cloud assets. However, if cookies were not reliably delivered, then the users are blocked and entering password will not help — the users will be permanently blocked. The users cannot utilize Chrome as is, because Chrome cannot deliver device information to the identity service for the policy evaluation. Depends on platform, the users have multiple options to unblock themselves:
- Use Chromium Edge — given that HTML engine is the same between Chrome and Edge they do not lose anything.
- Use FireFox, which has already integration with this feature ( https://support.mozilla.org/en-US/kb/windows-sso )
- Install one of our Chrome extensions (for example this one https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji), which uses native messaging host to integrate with this API.
-
For MacOS, iOS use Safari, as iOS, Apple supports alternative, but similar functionality:
ASAuthorizationSingleSignOnProvider | Apple Developer Documentation
WebKit/SOAuthorizationCoordinator.mm at main · WebKit/WebKit (github.com)
With respect to the extension model, it is naturally more complex, because it must consider 3P code, as a result has more failure points. Unfortunately, support story for the extensions is painful for us and our customers, and when we say people escalate to Google, they say that they cannot, and choose other options. Overall Chrome users experience degraded single sign on experience compared to Edge, FireFox or Safari population. They must pass extra 2FA and password prompts, unless they use the extension, while Edge, Safari and FireFox the users can skip these interrupts, if they used strong Windows logon credentials or passed 2FA in other applications (like Teams, Outlook etc.).
Overall, I would like to highlight this model is not only about SSO, SSO is a tip of the iceberg, we build a lot of features on it:
- Conditional access — granular control of access to the cloud resources (mentioned above).
- Enables protection of Identity artifacts against man-in-the-middle attacks by allowing Identity provider to issue shorter lived tokens that are bound to the device identity.
- Preventing extra password and 2FA prompt, minimizes the need for sending user’s password on the wire continuously.
As you already have noted, FireFox, Safari, Apple platform already supports this feature or similar feature, and we in constant collaboration with them. I agree with you, that there is lack of documentation and standardization, but the key players actively work on this, and it doesn’t stop them. I would like us to focus on the finding path forward, which from one hand will put Chrome on parity with Edge, Safari and FireFox at this aspect, from the other hand will formalize and find a path to close the gaps you mentioned:
- Missing documentation – we Microsoft, planning to publish code on github and fix documentation, to allow other browser to integrate.
- X-ms- headers – if needed we can agree on different header names, or remove x-ms- prefix 😊
- 3P integration — for now there is no 3P, as 3Ps are not willing, and they cannot appear without work on our end. Once 3P will express their interest, we are more than happy to work with them and you on topic you mentioned:
- Allow them to use headers vs cookies.
- Code isolation.
“This sort of thing doesn't have a path towards standardization or interoperability” — at this stage, other players already integrated with it, or have similar model (only Chrome, and Android doesn’t have similar model). Once we fix the documentation Opera and others will fix their browsers as well. Our extensions in total have 20M+ users – there is big demand on this. I don’t think this concern will stop key players, as there is demand on it. We cannot stop this, but we can lead it. We can work together on the path forward. However, while we were work on it, I prefer Chrome users experience a good experience.
What would be the next step in this area? Do you have a proposal for the path forward?
Ryan Sleevi
I think it is true for any authentication that part of Chrome, like Digest, Client TLS, Windows Integrated (NTLMv2, Kerberos) etc. I think the cookie cleanup will not prevent a web site that performs Windows Integrated authentication to know who you are. In this aspect it is a new form of Windows Integrated authentication, but more secure. I think Chrome implements Windows Integrated authentication as well as other forms of authentication, and not really concerned about it. From the other hand, a web app that integrated with IDP will lost its cookies and state on the cookie cleanup, and will have to start authentication process again, redirect to IDP, account consent if needed, etc. We also can discuss how we can support different browser profiles in this area.
Overall, I would like to highlight this model is not only about SSO, SSO is a tip of the iceberg, we build a lot of features on it:
- Conditional access — granular control of access to the cloud resources (mentioned above).
- Enables protection of Identity artifacts against man-in-the-middle attacks by allowing Identity provider to issue shorter lived tokens that are bound to the device identity.
- Preventing extra password and 2FA prompt, minimizes the need for sending user’s password on the wire continuously.
- Missing documentation – we Microsoft, planning to publish code on github and fix documentation, to allow other browser to integrate.
- X-ms- headers – if needed we can agree on different header names, or remove x-ms- prefix 😊
“This sort of thing doesn't have a path towards standardization or interoperability” — at this stage, other players already integrated with it, or have similar model (only Chrome, and Android doesn’t have similar model). Once we fix the documentation Opera and others will fix their browsers as well. Our extensions in total have 20M+ users – there is big demand on this. I don’t think this concern will stop key players, as there is demand on it. We cannot stop this, but we can lead it. We can work together on the path forward. However, while we were work on it, I prefer Chrome users experience a good experience.
What would be the next step in this area? Do you have a proposal for the path forward?
Sasha Tokarev
Hi Ryan,
Thank you for the chat.
Couple notes from me:
> If this is solely relegated to an Enterprise flag (and not even a user preference), I certainly am far less worried.
I think it will be very far from ideal, key part is that the user has joined his device and consented for SSO. They expect SSO. Having extra flag just extra useless hop, which adds friction without value. If users do not want to have SSO, they should not join. Extra policy/switch will kill authentication in Chrome for small businesses, because they will not know how to enable it, many organizations do not have big investment in IT department, as well as they allow use users’ personal devices, on which IT has limited control to enable some flag remotely. As a result it will make Chrome less attractive for such businesses.
> there have long been discussions about moving the entire authentication stack itself behind policy-gates
Discussion is one thing, but you haven’t done it, right? As Chrome will lost its attractiveness because IT folks will have to jump via extra hops, most likely will not find how to do it, and user have to switch on working browsers.
> … My worry is the pressures to more generally expose this (e.g. a user-level preference or a default-on) will, similar to the "lost decade" of NTLM/Kerberos interop online, end up with a de-facto standard that isn't well defined as to how it integrates.
The key difference here from other public auth schemes, that in a public auth protocol there is an assumption that somebody will implement those schemes, and an enterprise can setup a web auth service created by 3p developer. In the new approach it just us, we should validate our stuff, the rest of world integrates with us by OAuth. In a public auth protocol you need an extensive documentation and think what a behavior of web browser should be if an auth web server behavior is not legitimate. In the proposed scheme, you have only couple well-known IDPs, which you can easily identify, the behavior is well defined and documented. You can monitor and contact IDP any time. It is not 1000s of servers who implements kerberos worldwide, it just 2 services. Format/documentation of cookie-header has low relevance here, as it is our internal details.
> note that Chrome has already moved (similar to Edge) to restrict/disallow this in Incognito
Totally agree on this!
I think we could take Edge’s idea:
- default/first profile has this feature on.
- A secondary profile - by default off, but has a setting to turn it on.
- Incognito – can behave as a secondary or have some registry.
We also can discuss how to create profile for a different WebAccounts that you have on the system.
> It looks like Mozilla had similar concerns
Some of Mozilla concerns are the same, but some are different - I’m aware all of them, as I’m involved in that project as well. Regardless of their concerns - they shipped the first click stop.
With respect to documentation/header names, it is important for me to understand your commitments for this. As it is not cheap, if Chrome going to commit in this, we can discuss what is important for you, and do it fast, otherwise we will do it in our own pace.
> conditional access can be also viewed as a form of browser/vendor lock-in (which, as you note, may already be practiced, but not necessarily good)
I have multiple interpretation of this phrase in my head, but I’ll try to respond what I think is the most likely one. If it is about having some client-side code that prevents from some access (client-side security) it easy to work around by patching the code. Whatever we build, as well as some other vendors, we deliver device id to the server, and the server decides “issues/not issues token” based on the state of device, and its history. It is way harder to compromise many signals that comes from device over time vs patching the client code.
> the binding to device identity equally normalizes persistent online tracking in ways that may be coopted for less-than-noble purposes (e.g. attempts to legislate out online anonymity)
I think it is important to highlight here, that IDP knows device (and the user has consented it), but the calling web-application not mandatory (it really depends what IDP renders in the token). I share your device online anonymity (that is why I agree that in Incognito mode we should have this stuff off), but our job is keeping balances between privacy, security, and features. If the user has made the extra steps to join the device to IDP, then I don’t think we should challenge that user made a wrong decision. The users always can unjoin, if they do not trust IDP, or IDP compromised their trust.
> the primary way of doing that is through encouraging greater centralization of identity services.
And this where this feature will help 😊
Thank you,
Sasha
From: Ryan Sleevi <rsl...@chromium.org>
Sent: Tuesday, October 26, 2021 12:03 PM
To: Sasha Tokarev <ale...@microsoft.com>
Cc: rsl...@chromium.org; zm...@chromium.org; blin...@chromium.org; g...@chromium.org; mme...@chromium.org; a...@chromium.org; yhi...@chromium.org; pasta...@chromium.org
Subject: Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome
Sasha Tokarev
Hi Matt,
I missed that you asked some questions inline, sorry about that, I’ll cover answers inline as well.
From: Matt Menke <mme...@chromium.org>
Sent: Saturday, September 25, 2021 7:45 PM
To: Sasha Tokarev <ale...@microsoft.com>
Cc: Owen Min <zm...@chromium.org>; blink-dev <blin...@chromium.org>; Greg Thompson <g...@chromium.org>; Ryan Sleevi <rsl...@chromium.org>; Adam Langley <a...@chromium.org>
Subject: Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome
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 <ale...@microsoft.com> 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:
Thanks! So this is a per-local-app permission, that can also be granted to all apps? (Sasha: yes, if the user consents) My main concerns, in terms of privacy (not security issues) here are:
- 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.
Sasha: An extra settings just an extra friction, the user has consented, and user expects SSO, otherwise it should not join the device.
2) An enterprise uses corp Microsoft accounts, but doesn't want to use Microsoft as an IDP. (Sasha: it should not join device to Microsoft IDP then) 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. (Sasha: Non-Microsoft accounts do not exist, but if they were, then I don’t think it is an issue if the user has consented to it.)
- 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.
Sasha: Currently, your personal cookie will not go to your organization’s IDP, because our IDPs are segregated, and every IDP has associated list of URLs, an IDP gets the cookie for
its URL .However, if IDP handles both personal and work identity, then it will get both cookies, and it will be IDP’s job to ask the user which account he/she is going to use for this application. However, there 2 things should happened for this scenario,
the IDP needs to handle both Organizational and Personal identity, the application should be registered in a way that it handles personal and organizational accounts. If that will happened, then the IDP will have to ask the user which account to use, something
like this:
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.
Sasha: Admin needs to pre-install application in the tenant, otherwise it will be rejetected. This concern also exists without this feature. A user has Office,
- the user logged in Office via IDP (login.microsoftonline.com)
- login.microsofonline.com will store it as a cookie.
- Now, sasha.com can silently bounce the user via login.microsfotonline.com, get a token and read user’s email. It is a huge issue, if it would be possible.
That is why:
Before sasha.com start to work in the tenant, admin needs to pre-install/pre-consent the application in the tenant.
I’m on purpose drawing parallel with cookie, because in this proposal, the only thing we append a way how we deliver the cookie, the remaining model stays the same. All threats that applicable for cookies, are also applicable for this model.
Configure the admin consent workflow - Azure AD | Microsoft Docs
> 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'm not suggesting a threat here, just trying to understand what information is used by the server to authenticate users (which, sure, I want to know so I can figure out the worst that can happen in the case of a malicious actor).
Sasha: in the moment of Windows logon, or application logon the IDP web site creates an encrypted blob, that has user information, device information and session key. Nobody except server can decrypt this blob. We call this blob as PRT or authentication artifact. When a web request goes to IDP, and only to IDP (not other web site), we take request QS parameters that may include nonce, PRT and sign this request by the session key that stored in TPM. When the request reaches the server, we:
- Validate nonce.
- Decrypt PRT, extract Session key from it.
- Validate signature of the cookie.
- If the signature is valid, the server takes device id and user id information from the blob.
Here is example of the cookie, you can use any JWT parser to decode to some level, eyJhbGciOiJIUzI1NiIsICJjdHgiOiIwcDRXekZ6TlF1TnhjakRCRjBlOUtNQk9nSXNlUDdZMSJ9.eyJyZWZyZXNoX3Rva2VuIjoiSUFRQUJBQUFBQUFBbS0wNmJsQkUxVHBWTWlsOEtQUTQxNEhpZllLbVIwcTBOdlZ5SXYwNlY4Ujc2Rkt3SzV4SWd6NHlXMUJBSU5QNXZEekl4VGc4cXV1V25oaVY4TDEzZHIyNWtNVWxMU0t2VDVTcEFrNEhKQnRDTTFKbm43dzlZRkpCWlBoWnFwcE5lOXIzWGxEV0NLOFkwWVhoRC0wQV8yTkVIRkQzbG1RcEdNd1VkcGUtS2hiWjBNNDZ0aTFsYkVVR2RGNWRuc0c1R1pYYThoNzdTV1Fqay1TY2NETVA2Tnh0aDNRQzhRYV9zZ255Q2FQYVZKanBZaVhFYmFIajNTb0RDYS1Yb1RHQ192Q2JpaVhQX2NyWFZtSVhzQkZBSDg1WnFqYUhQYThlVTYwMTVINThOTmVJTll5VTlsVDFYeXZmanE5RXZ2QloyR1RIRU02MnNJWXR2SmkzQk1SeGJoLXB1cEV0UVpfY1doNEdLSXVBM2JrMFdHdUZVT3pnQmpGaERyWUk5aDJJLVVXUGF3cHFiTFJXbEZmejk5VDFsMnlFYVZlQ29uemotSHZYSVBCVjZfaEU0TUtYajh2T1pqV3ltelVnQmtvMVhqQlNyWkg4ZG1MMm9oX1BBU29oQWN4c2h2LXAwU05FTW1tQ1hPa1VwU2t0aXNhZkxNYUY5SnhMVW80dGVYanFLc1NDT2o0QURfYjZhQ2MybEY1dnpQWTdZNjdMVlVYZDRvYmkyX2RpOXJDbVQtLWVacXRHY25kMENUQmFvTWh5U0RrMTlqcVE5QVF0dGFRTnV6OTV3LVVCaEEyd09wRzVnaVNLM2tOOEhfZ0VhSF9ubjdaX2FQeU1GR1BfQ0VxNWppZTJjOGF5aWdmX2tjdjNHSWVfVGhfeFROSThjNE5JaWp2NWdCaEpCWU15R0NVejJfMEg2MnRUenJac1ZRYTIwTmphZlpVd3pxQ24xTDIwUnJNcUF4U2dwQzlYc1ZTcWY0WDEtRDBQRDB4WjdyYWR5U2RoWkV2X0FIV05PWGhiUk5oLXktem5JYV9LV2lvcnRxSWw3aW05ZzVWZzFmUTZuLThxUTRkWTUxM1pOTUI1SG03dks2emlJM19ORFdBUmdWU1VjekRGaUNnQ0lUWlVjdGQ2eW5Xbk9ZNnFiaVAxMFJjejZ2T2VjMzNsUHhaWTI2VnkwN1UwLUtHUEZnYlB4NmViM0dwY1c0MElLdmVaT2dnM2VDdkx1MkM0MHhsSnJYcnhEVmZBMGY2bTh3VWktVENRLWJEc2tzNEF3S1VHRk1YSUlzeF9ZaVlEMWd6OGoxYTJyRS1JVnM0OVJCMDNCQjlla2cwUVV4X2NPS0Z3dnpXdWt6Vkd4dFY0SWVjMGVXa21pLW9aR1NxVXVrWlpGMHdqZmpYckxBTExiTEQ2QmZQSl9oRGxxMnNGcHFibGtrN0tGMmZiQ0hudm03eFN0ZTYwMzlZRGNrZ3FpU3pfb3FhYk5Kb2JWdFdoRGNNNDlnb29SdXdpNERJbC1EVjFUWVhucVBpSnl1WWpOQlM5WjE2S2ZZQmtKdGtwblhlbW8tSDh0YlRNaUNvZXF1eEZFTFJKc0MxU0xEVUVQbjl5eEVaLWFlRno4N2xRNC1KQk9feHNxM09BWFMydXNJd3U0ZmpSTkRPM25QMllUYmFRTlNxamNvYnV3T1RMSGJJNVV3UFlTU19nUkFPdkRGbi1hNDRudWN0azBKcExTVXRrQVlFajBFWmVwYjIySDFfOTctal9fNERvM0FxVTBQTURfNFJUM1preHgyMUJJdkxmUWt1XzU3dVZ3WGtNdzNud2JxTUJKSUFBIiwgImlzX3ByaW1hcnkiOiJ0cnVlIiwgInJlcXVlc3Rfbm9uY2UiOiJBUUFCQUFBQUFBQW0tMDZibEJFMVRwVk1pbDhLUFE0MVhKWmVNb3MxSmxubzZuZXNBbVR1VEl2VTdLZUs3LXZab1dJR0JGdmNzZHNtb1ZUR2ZxOHdNZlVYRW9sRWE0c1h2bXZPQjBtemdNV0V4bFdhbTUzNWZDQUEifQ.ah99UVhYNBp2KoKx5I3yLbzdf01nV0nicPPCf43uMMw
However, you will not be able to open refresh_token field, as it is encrypted by a server key.
What happens if the cookie is rejected?
Sasha: IDP will try to ask username and password, 2FA, however if the admin wants to validate the state of device, and device will not be delivered, the user will blocked.
Could an MitM attacker figure out if the cookie is rejected or not by whether the user was redirected from the IDP to the destination site?
Sasha: this question I didn’t fully understand. Overall MitM can conclude that cookie was rejected.
> 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.
So not just all navigations, but also XHRs and subresource requests, then? (Sasha: yes if they go to IDP) What about internal Chrome requests? (Sasha: Chrome is not integrated with IDPs that on Windows, but if it will – then yes) These are non-webby requests, but I believe some enterprise policies may trigger them (e.g., installing extensions mandated by group policy). (Sasha: I don’t think we care about them, these requests do not have integration with our IDP.)
Should enabling 3P cookie blocking also block these, in contexts where we consider the IDP server a 3P server?
These sound like SameSite=None cookies, which are slated for removal from the web platform. Admittedly, partitioned cookies will be added before that, though since these aren't really partitioned, it's not accurate to call these partitioned cookies, since they give a cross-site identity. Clearing all cookies also clears cookies (whether the user does it, or it's done by a Clear-Site-Data header), while the state maintained by these is persistent. These are also not scoped per Chrome profile, unlike cookies. So I'm not sure saying these must follow all cookie rules is accurate here. I'd be more comfortable not overloading the cookie request header.
Sasha: I would consider them as 1st party cookies, as an IDP creates cookie for itself. The cookie is created by login.microsoftonline.com/live.com for itself ( login.micosofotonline.com/live.com ), but outside of browser during windows logon/application logon. Clean all the cookies will not actually clean them (they will be re-created), and yes in this aspect it is auth 😊
Sasha Tokarev
(Sorry for duplication, but I don’t see this response in the public thread, probably because I’ve sent it from my private email and it went to some filters, so I’m repeating it from my official with some additions)
I would like to highlight one important conception of “joined device". If a user/admin went through the joining process, they consented and expect:
- browser SSO
- application SSO
- access to protected services from a web and a native applications
Otherwise, they should not join.
While privacy and security concerns are important, we should agree that it is IDP job to balance all parties in process of authentication, and they always exist, given we have centralized identity service, and IDP use cookies.
Joining of the device is an explicit, and in some case not a trivial action from a device owner (in case of personal devices the device owner == the user), an extra flag in this process makes this feature unusable for some cases. With respect to security and privacy aspects, there is no essential difference in the IDP behavior between a web application and a native application (browser SSO and application SSO), if the device owner doesn’t like the IDP behavior, he/she needs to unjoin.
Thank you,
Sasha
Matt Menke
Sasha Tokarev
Hi Matt,
I apologize for not being able to respond, I was on vacation, but now I’m back. However, before the vacation, I had planned to ping this thread, as we are getting more and more feedback that the extension model is not working for various reasons, and the users do not have sufficient help to resolve it. In many cases the extension is either accidentally dismissed, or partially works (has icon on tab, but the rest functionality is blocked). In such cases we suggest to escalate to Google, but I’ve been seeing very few cases that successfully got attention from Google.
You can read review feedback here:
https://chrome.google.com/webstore/detail/windows-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji
In such cases the only recommendation we have is “use Edge”, as it has the native support and not a subject for the extension deployment issues. In order to reduce support cost, we are also considering to change our remediation page, which we show when the users hit the conditional access issues, to detect such cases and show more explicit text to use Edge. I’m hopping we will be able to make a progress on this.
Back to your question:
* Do we need to bypass CORS for requests send to Microsoft's IDP?
- no you don’t need. It is ok to respect CORS.
* Do we need to send Microsoft SSO credentials in Credentials Mode: Omit requests?
- I assume you meant this XHR requests with credentials? https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials
We don’t use XHR for authentication for now. So, if it is more simple, we can agree on “no”.
* Do we need to send SSO credentials in sandboxed iframes of fenced frames?
- no. I’ve synced up internally, we don’t use fenced frames, but we use iframes (on the application page) for some authentications. So, this headers should be available in iframes of the application page.
Thank you,
Sasha
Matt Menke
Hi Matt,
I apologize for not being able to respond, I was on vacation, but now I’m back. However, before the vacation, I had planned to ping this thread, as we are getting more and more feedback that the extension model is not working for various reasons, and the users do not have sufficient help to resolve it. In many cases the extension is either accidentally dismissed, or partially works (has icon on tab, but the rest functionality is blocked). In such cases we suggest to escalate to Google, but I’ve been seeing very few cases that successfully got attention from Google.
You can read review feedback here:
https://chrome.google.com/webstore/detail/windows-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji
In such cases the only recommendation we have is “use Edge”, as it has the native support and not a subject for the extension deployment issues. In order to reduce support cost, we are also considering to change our remediation page, which we show when the users hit the conditional access issues, to detect such cases and show more explicit text to use Edge. I’m hopping we will be able to make a progress on this.
Back to your question:
* Do we need to bypass CORS for requests send to Microsoft's IDP?
- no you don’t need. It is ok to respect CORS.
* Do we need to send Microsoft SSO credentials in Credentials Mode: Omit requests?
- I assume you meant this XHR requests with credentials? https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials
We don’t use XHR for authentication for now. So, if it is more simple, we can agree on “no”.
* Do we need to send SSO credentials in sandboxed iframes of fenced frames?
- no. I’ve synced up internally, we don’t use fenced frames, but we use iframes (on the application page) for some authentications. So, this headers should be available in iframes of the application page.
Sasha Tokarev
With respect to credential mode “omit” it is fine not send those headers, if the other mode will allow it.
We use sandboxed iframes in out authentication libs, but we set “allow-same-origin” token to be able to use cookies.
We fine if “allow-same-origin” will relax restriction of not sending cookies.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox
John Abd-El-Malek
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH0PR00MB1313E2E1FE66EEFFD8F75BAEA1649%40PH0PR00MB1313.namprd00.prod.outlook.com.
Sasha Tokarev
Hi John,
Sorry for the delay.
1) Can we avoid modifying the Cookie header, and only modify "x-ms-" headers?
- No, in some version of windows we use Cookie instead of headers.
2) Can this be scoped to just frame requests, e.g. only for requests to fetch the html for main frames and subframes and not subresource requests like images, XHR, JS, CSS etc. requests? Igor had tried this locally and it seemed to work.
- some customers have a proxy, which redirects to all requests, including from images to their internal service, authenticates the user via AAD and redirects back if this request is authorized to the user. Can you do it for frame request only – yes, and it will cover most of the scenarios, but the previous one will not work in Chrome. My recommendation would be to do in all requests.
Thank you,
Sasha
From: John Abd-El-Malek <j...@chromium.org>
Sent: Tuesday, October 18, 2022 12:58 PM
To: Sasha Tokarev <ale...@microsoft.com>
Cc: Matt Menke <mme...@chromium.org>; blink-dev <blin...@chromium.org>; Owen Min <zm...@chromium.org>; Greg Thompson <g...@chromium.org>; Ryan Sleevi <rsl...@chromium.org>; Adam Langley <a...@chromium.org>
Subject: Re: [blink-dev] RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome
|
You don't often get email from j...@chromium.org. Learn why this is important |
Matt Menke
Hi John,
Sorry for the delay.
1) Can we avoid modifying the Cookie header, and only modify "x-ms-" headers?
- No, in some version of windows we use Cookie instead of headers.