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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fevil.com%2F&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296227472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8mZUTvFB1vrlxQNfNP2PQnzhVYLnwtD09CLUiqm7SI8%3D&reserved=0> > could redirect to > https://login.microsoftonline.com/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogin.microsoftonline.com%2F&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296237374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=B4ZotsvVWhTesV1o4bXJUS9GaGKsF0UvBA%2Bra9BWmn8%3D&reserved=0>, > and tell it to log in using the IDP to > https://www.mywork.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mywork.com%2F&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296237374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Fb3gSUH4%2B%2BZRN02BynDXfKBpE1cPQ%2FaJuowthjrM3kA%3D&reserved=0>, > 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<https://www.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<https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token>, 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: 1. During Windows logon 2. Application logon (if user has added account), e.g., when Outlook accessing Exchange. Browser just reads PRT-cookie. Thank you, Aleksandr From: Matt Menke <mme...@chromium.org> Sent: Saturday, September 25, 2021 1:37 PM To: Owen Min <z...@chromium.org> Cc: blink-dev <blink-dev@chromium.org>; Sasha Tokarev <alex...@microsoft.com>; Greg Thompson <g...@chromium.org>; Ryan Sleevi <rsle...@chromium.org>; Adam Langley <a...@chromium.org> Subject: [EXTERNAL] Re: Native support of Windows SSO in Chrome 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 <z...@chromium.org<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. 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchrome.google.com%2Fwebstore%2Fdetail%2Fwindows-10-accounts%2Fppnbnpeolgkicgegkbkbjmhlideopiji&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296207395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=u%2FaG7%2BNIgv58WLgTQFOqLwU30z3Cpw81wGrb47M%2FyMo%3D&reserved=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&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296217385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Dmq8hJJwtnuT8AICp3q%2BRF0SMYM4OTF1Nj%2FWbvd5Xus%3D&reserved=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&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296217385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AmGYmmz61X1ksh5uGnKmJ10nj2UhU%2BxeXgqB%2BbW6r0w%3D&reserved=0>). The request will have a redirect URI that IDP will use to return a token. So this means evil.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fevil.com%2F&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296227472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8mZUTvFB1vrlxQNfNP2PQnzhVYLnwtD09CLUiqm7SI8%3D&reserved=0> could redirect to https://login.microsoftonline.com/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogin.microsoftonline.com%2F&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296237374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=B4ZotsvVWhTesV1o4bXJUS9GaGKsF0UvBA%2Bra9BWmn8%3D&reserved=0>, and tell it to log in using the IDP to https://www.mywork.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mywork.com%2F&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296237374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Fb3gSUH4%2B%2BZRN02BynDXfKBpE1cPQ%2FaJuowthjrM3kA%3D&reserved=0>, 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogin.microsoftonline.com%2F&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296247373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Yfa4AJHUABDTsX6JjZFVMSn4r9wyxe2YJxV5ll6u3i0%3D&reserved=0> ): * 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? * * 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. 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 disclosure. 2. 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc6749%23section-3.1.2&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296247373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6QzeBiH1ZAZU%2Fj1nVE7Dhq0DvrJB4zC0WFe4NdfZCrE%3D&reserved=0> 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/SN6PR00MB0381E29D195C9092310CB3D8A1A69%40SN6PR00MB0381.namprd00.prod.outlook.com.
