This task is being picked up again, but there are a lot of questions in terms of implementation:
* Do we need to send Microsoft SSO credentials in Credentials Mode: Omit requests? * Do we need to bypass CORS for requests send to Microsoft's IDP? This is a bit related to the above question. * Do we need to send SSO credentials in sandboxed iframes of fenced frames? I'm hoping the answer to all of these is "no", so these behave a bit like 3P cookies (which are being removed from the web platform...). On Wednesday, November 3, 2021 at 11:12:16 AM UTC-4 Sasha Tokarev wrote: > (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: > > > > 1. browser SSO > 2. application SSO > 3. 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 > > > > > > *From:* Sasha Tokarev > *Sent:* Tuesday, November 2, 2021 6:33 PM > *To:* 'Matt Menke' <[email protected]> > *Cc:* Owen Min <[email protected]>; blink-dev <[email protected]>; > Greg Thompson <[email protected]>; Ryan Sleevi <[email protected]>; > Adam Langley <[email protected]> > *Subject:* RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome > > > > Hi Matt, > > > > I missed that you asked some questions inline, sorry about that, I’ll > cover answers *inline* as well. > > > > *From:* Matt Menke <[email protected]> > *Sent:* Saturday, September 25, 2021 7:45 PM > *To:* Sasha Tokarev <[email protected]> > *Cc:* Owen Min <[email protected]>; blink-dev <[email protected]>; > Greg Thompson <[email protected]>; Ryan Sleevi <[email protected]>; > Adam Langley <[email protected]> > *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 <[email protected]> > 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? (*Sasha: yes, if the user consents)* 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. > > > > *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.)* > > > > 1. 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, * > > 1. *the user logged in Office via IDP (login.microsoftonline.com > <http://login.microsoftonline.com>)* > 2. *login.microsofonline.com <http://login.microsofonline.com> will > store it as a cookie.* > 3. *Now, sasha.com <http://sasha.com> can silently bounce the user via > login.microsfotonline.com <http://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 <http://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 > <https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow> > > > > *> 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%7C85ba6258b21a41bd4dd108d98097af2e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637682211294413165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DcBnW9BJhM%2FYdmLYpUrUJIkBJ20D2htYR7IQGu36VzE%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%7C85ba6258b21a41bd4dd108d98097af2e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637682211294413165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V47GSvdxd9xiT1KPChBZ3SSoxr8act6oVVi2e%2BDDaCY%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%7C85ba6258b21a41bd4dd108d98097af2e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637682211294423161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Q0BoPdet2IyxoSWybvV8yZphJfZiJRhGDkwMJDNPLfs%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mywork.com%2F&data=04%7C01%7Calextok%40microsoft.com%7C85ba6258b21a41bd4dd108d98097af2e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637682211294423161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Q0BoPdet2IyxoSWybvV8yZphJfZiJRhGDkwMJDNPLfs%3D&reserved=0>’s > > redirect URI, it means that token (authentication artifact) will be > delivered 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%7C85ba6258b21a41bd4dd108d98097af2e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637682211294433155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yHra%2BN%2BYJXFAl42%2FQy1NhXYTchZmIIDl5DeJuixSIGY%3D&reserved=0> > > not to evil.com > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fevil.com%2F&data=04%7C01%7Calextok%40microsoft.com%7C85ba6258b21a41bd4dd108d98097af2e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637682211294433155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=W6CeXJ%2FHM0db5GP%2BtmwkJjwQtmD1Pbk5u3EXaGRdX9Q%3D&reserved=0>. > > 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:* > > 1. *Validate nonce.* > 2. *Decrypt PRT, extract Session key from it.* > 3. *Validate signature of the cookie.* > 4. *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 > <http://login.microsoftonline.com/live.com> for itself ( > login.micosofotonline.com/live.com > <http://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 **😊* > > > > *> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fdevices%2Fconcept-primary-refresh-token&data=04%7C01%7Calextok%40microsoft.com%7C85ba6258b21a41bd4dd108d98097af2e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637682211294443150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hdUrs0mJ7ylTsNpAs2A5i%2F6Rmshs1IF%2FrPnQeb%2Fym2o%3D&reserved=0>, > > 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 > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0c99839f-ba99-48e3-a1a1-9f1c3f517db0n%40chromium.org.
