+Yulian Pastarmov <pastarm...@chromium.org> On Sun, Sep 26, 2021 at 11:34 AM Ryan Sleevi <rsle...@chromium.org> wrote:
> Thanks for the super-detailed response Aleksander! To reflect what Matt > said, don't feel the need to respond on vacation :) > > Regarding the forks: I suspect this might be how GMail vs Outlook differ > in managing threads, since in Google Groups and GMails, it appears as all > one conversation > <https://groups.google.com/a/chromium.org/g/blink-dev/c/zJpLAAz4RtE/m/gZ9RwDqmBAAJ>, > not as forks. You shouldn't have to worry too much about it :) > > This was a super-helpful response, and I think it teases out a few things > worth digging into further. > > From your remark about WAM, it seems like this is a generic extensibility > framework <https://channel9.msdn.com/Events/Build/2015/2-709>, for any > IDP - from Microsoft, Google, Okta, etc - to be able to hook the not only > the browser's network stack (effectively), but any consenting applications' > network stacks, and be able to inject arbitrary cookie names and values > <https://docs.microsoft.com/en-us/uwp/api/windows.security.authentication.web.provider.webaccountproviderretrievecookiesoperation?view=winrt-20348>. > It appears these providers may be device-wide (although only Microsoft > IdPs > <https://docs.microsoft.com/en-us/uwp/api/windows.security.credentials.webaccountprovider.issystemprovider?view=winrt-20348#Windows_Security_Credentials_WebAccountProvider_IsSystemProvider> > are supported for that), but are primarily user-wide. If I'm understanding > correctly, any IdP application can register to be the handler > <https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-uap-webaccountprovider> > for a given IdP URL. > > It seems, from my limited understanding, to be a bit like an OS extension, > rather than a browser extension - and to allow third-party software to > affect the authentication flow, not only within a browser, but within all > apps (that opt-in to supporting this). Although Windows already had an > extensible API for adding authentication providers - SSPI and the Negotiate > method - it has the downsides I mentioned in my previous e-mail, of being > incompatible with modern transport technologies, as well as being a hugely > complex thing to implement client and server (CredMan > <https://docs.microsoft.com/en-us/windows/win32/secauthn/winlogon-and-credential-providers> > is easier than GINA > <https://docs.microsoft.com/en-us/windows/win32/secauthn/winlogon-and-gina>, > but not by much, and SSP/APs > <https://docs.microsoft.com/en-us/windows/win32/secauthn/creating-custom-security-packages> > aren't fun to write, and it seems like this is the next evolution in this > space, ignoring ADAL/MSAL > <https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-overview> > :D). I'm just trying to make sure I understand the space of where this > fits, on the Windows side of things, since that helps inform a bit how > we've evaluated security/privacy risks in the past. > > Architecturally, as it relates to Chrome/Chromium, this seems a little > like offering an OS-provided pluggable OAuth2 Access Token Manager > <https://source.chromium.org/chromium/chromium/src/+/main:google_apis/gaia/;drc=58df57696ad9b3eb757ebb80c9dfe8318d4b0674>, > except further, not bounded to having to use OAuth2. Conceptually, a > browser wide notion of the current user's identity, which can be provided > to websites as needed. Unlike the current implementation, rather than > triggered by signing in to the browser, it's provided by the OS's > extensibility framework and signing into the OS itself. Is that at least > conceptually right? That is, if you sign in to Chrome today, and then a web > resource wants to go through Google's IdP, Chrome is able to make the > user's logged in state available to the IdP, creating a frictionless flow > between the browser content and the Web content, similar (though not > identical) to the Desktop Identity Consistency effort - where signing in to > the IdP in the Web allows you to sign in to Chrome (the app). > > Assuming I haven't bungled things too much yet, a specific question is > whether WAM is what serves as the backing implementation for > IProofOfPossessionCookieInfoManager::GetCookieInfoForUri > <https://docs.microsoft.com/en-us/windows/win32/api/proofofpossessioncookieinfo/nn-proofofpossessioncookieinfo-iproofofpossessioncookieinfomanager>. > The WAM remarks are all .NET managed code, and it sounds like this COM > interface provides a handy abstraction around that logic. For example, for > a given URI, it would see if it matches one of the web account provider's > managedUrls, and if so, call RetrieveCookies on the web account provider, > and then make those available via cookieInfoCount/cookieInfo. If no > provider was registered, I imagine it'd just return no cookies. I have no > idea if this is remotely correct, and if I've completely bungled it, I was > hoping you could explain the relationship between WAM and > IProofOfPossessionCookieInfoManager :) I also wasn't sure if the proposal > here was that Chrome should be calling WAM directly (via a Managed DLL), or > if using COM is the recommended approach. > > 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? > > Before I ask more follow-up questions about the browser-side > implementation, I figure this is probably a good checkpoint to make sure I > haven't completely bungled everything. > > On Sun, Sep 26, 2021 at 3:25 AM Sasha Tokarev <alex...@microsoft.com> > wrote: > >> 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 >> <z...@chromium.org> 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 >> <https://docs.microsoft.com/en-us/uwp/api/windows.security.authentication.web.provider?view=winrt-20348> >> (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. >> >> 1. *User* opens Word, and enters his/her Gmail account to access >> Google Drive, in Google WAM plugin (relationship between User and Google) >> 2. *Google WAM Plugin* asks “Do you want add this account to Windows >> and able to access Google services from everywhere other applications and >> web?” >> 3. *User* clicks yes. >> 4. *Google WAM plugin* creates SSO artifact, and creates account in >> the system, user can control it from Settings. >> 5. *User* launches Outlook and Outlooks and can read Gmail from >> Outlook. >> 6. *User* opens a web browser Edge, IE, FireFox, Chrome navigates to >> gmail.com. >> 1. *Gmail.com* navigates to accounts.google.com >> 2. *Web browser* sees that accounts.google.com in a registered Url >> list. >> 3. *Web browser* calls api to pull the cookies GetCookieForUri >> >> <https://docs.microsoft.com/en-us/windows/win32/api/proofofpossessioncookieinfo/nf-proofofpossessioncookieinfo-iproofofpossessioncookieinfomanager-getcookieinfoforuri> >> . >> 4. *Web browser* appends these cookies to the request to >> accounts.google.com >> 5. *Account.google.com <http://Account.google.com>* validates >> cookies and proof of possession authenticates the user and redirect >> back to >> Gmail.com with token. >> 6. *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. >> >> >> >> >> >> 1. >> 2. *Validates if the resource owner (enterprise admin or user) >> authorizes access to the resource.* >> 3. *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: >> >> 1. Browser reads list of urls from OS >> 2. If navigation happens for an interesting URL, then browser should >> call API to get cookies or headers. >> 3. Browser appends cookies or headers to the request. >> 4. 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 <rsle...@chromium.org> >> *Sent:* Saturday, September 25, 2021 11:17 AM >> *To:* Owen Min <z...@chromium.org> >> *Cc:* blink-dev <blink-dev@chromium.org>; Sasha Tokarev < >> alex...@microsoft.com>; Greg Thompson <g...@chromium.org>; Matt Menke < >> mme...@chromium.org>; Ryan Sleevi <rsle...@chromium.org>; Adam Langley < >> a...@chromium.org>; Yutaka Hirano <yhir...@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! >> >> >> >> I have a lot of questions below, so hopefully it's not overwhelming. This >> is certainly a very interesting space, and a great chance to modernize >> things, but also seems like it poses some unique risks. >> >> >> >> On Thu, Sep 23, 2021 at 5:18 PM Owen Min <z...@chromium.org> wrote: >> >> +people who may be interested in this. >> >> On Thursday, September 23, 2021 at 12:21:51 PM UTC-4 Sasha Tokarev wrote: >> >> Hi all, >> >> I have a proposal to integration with Windows SSO in Chrome. >> >> Currently Windows has ability to join device to cloud identity, like AAD, >> MSA. When a device is joined to a cloud identity provider (IDP), it would >> be great if I’m as a user do not need enter credentials, when I’m using a >> service, which uses IDP where my device is joined to. I’m consented to have >> single sign on (SSO) when I joined the device, and trust IDP to protect my >> identity and do not allow an authorized access. If I do not trust, I should >> not join my device. Additionally, sometimes web resources, that I’m >> accessing to as a user, are owned by organization where I work or study. >> Hence, an organization administrator should be able to manage access to >> such resources based on the quality of my device, e.g., prevent access if >> the device doesn’t make malware scans or doesn’t have latest security >> patches etc. >> >> Edge has this feature built in, in Chrome we must use a special extension >> https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchrome.google.com%2Fwebstore%2Fdetail%2Fwindows-10-accounts%2Fppnbnpeolgkicgegkbkbjmhlideopiji&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597816979%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EPWwy814QsxgN9I%2FqXA3owMHcl%2FP%2BTQMWiWTAtrm9cQ%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. >> >> >> >> Is there a public specification for this flow? For example, with existing >> OS SSO integration, we have a standard set of APIs (GSS-API on Posix >> platforms, SSPI on Windows, which are both conceptually similar), and a set >> of specifications for how they interact with Web technologies. >> >> >> >> I ask, because Negotiate/Kerberos/NTLM integration is already >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fietf-http-wg%2F2012AprJun%2F0690.html&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597826974%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wQ0dtnzzRXcFgjLbne%2Bqz%2F70x3grYDD5DLw4rLyf%2Fv8%3D&reserved=0> >> a bit of an outlier >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7235%23section-5.1.2&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597836979%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AY286MUj4hCo%2FmGVDuc4PC2j86rQ%2FqnBjPIQB2OAHGg%3D&reserved=0>, >> in that it didn't follow the WWW-Authenticate or HTTP semantics. This makes >> it challenging to support in new protocols (e.g. HTTP/2 or HTTP/3). It >> seems like, as part of this, having a sense for the specification would be >> very helpful here. >> >> >> >> >> 1. *Resource* (e.g., www.mywork.com >> >> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mywork.com%2F&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597836979%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WJWyylDqFui8UaNcrKOuDhKdNeIb01hUsx1Ia0Q6LkU%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%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597846970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5kzfSLO8COAFQfvOte9mEN1%2FyLclYdiuiuD%2Fa00kPHQ%3D&reserved=0>). >> The request will have a redirect URI that IDP will use to return a token. >> 2. *User agent* (Chrome) will detect this navigation and call an OS >> API for producing a crypto-protected SSO cookies, which has device and >> user >> information. This cookie will be appended to the request as a header or >> cookie. >> >> Could you expand on this "header or cookie"? That is, appending cookies >> from the OS introduces a whole host of complexity considerations, and has >> to be reasoned about through the network stack. For example, I can imagine >> issues if we persisted those cookies to disk, since it sounds like the >> intent is that the cookie value is actually some ephemeral >> nonce-like/time-bounded thing. This gets messy when merging, and of course, >> from a privacy angle, when clearing. Having a bit of semantic separation at >> the transport layer, like a header, seems useful. This is the first I've >> heard in the context of this feature that a header is viable, and would >> love to understand and explore that more, because it might address a number >> of the concerns/considerations. >> >> >> >> >> 1. >> 2. *Cloud identity provider* ( https://login.microsoftonline.com >> >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogin.microsoftonline.com%2F&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597846970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5kzfSLO8COAFQfvOte9mEN1%2FyLclYdiuiuD%2Fa00kPHQ%3D&reserved=0> >> ): >> >> >> 1. Detects presence of the SSO cookies, validates them by checking >> signature, and authenticates the user and device. >> 2. Validates that the supplied redirect uri is registered for this >> application. >> >> From a threat model standpoint, this makes a lot of sense when OS vendor >> == Browser vendor == Identity Provider. If you don't trust them, really the >> whole system collapses. >> >> >> >> This seems a little more difficult when OS vendor != Browser vendor != >> Identity Provider, because the responsibilities for privacy and security >> get divvied up among multiple stakeholders. >> >> >> >> That is, in the worst case, it seems like a vulnerability in the IDP >> provider can make the browsing experience unsafe, and the responsibility >> for that failure will be shared (i.e. users will blame the browser for >> exposing the feature, and the IDP for failing to secure it appropriately). >> Do you have any thoughts on how the browser can help make sure that the IdP >> is acting in the best interests of the user? >> >> >> >> It sounds like the assumption here is that the user will explicitly >> accept this risk when they configure the OS for the IdP, is that right? In >> that model, how can the browser be sure the user made an informed choice, >> and affirmatively wants the browser to behave this way? 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? >> >> >> >> >> 1. >> 2. Validates if the resource owner (enterprise admin or user) >> authorizes access to the resource. >> 3. 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). >> >> >> >> >> 1. >> 2. Read device identity, and checks the state of device, that >> reported out of band by device management system. >> 3. 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. >> >> 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? >> >> >> >> >> 1. >> 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. >> >> >> >> 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? >> >> >> >> And is it correct that when you say "enterprise account", this is in >> reference to the IdP's notion, not the OS/browser notion? >> >> >> >> 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%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597856953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TYkKFJeNBwE1JCncmKJ36M2KjSB73K0DkWtPBzt%2BUpo%3D&reserved=0> >> >> >> >> This is where having a clearer protocol specification will be useful. For >> example, the OpenID Foundation is working on making it easier for RPs and >> IdPs to establish relationships, through the FastFed Working Group >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fwg%2Ffastfed%2F&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597856953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bs%2F6oIObhSvihiKJBDvmSpgaXU%2FeioazzKOT2JgZLXs%3D&reserved=0>. >> I recently shared some concerns >> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fpipermail%2Fopenid-specs-fastfed%2FWeek-of-Mon-20210823%2F000358.html&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597866965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FN%2F%2BkVCqCpAnA%2BLmeDCwmqFrFxMwQb4dKvfrybOCLMw%3D&reserved=0> >> with some of the current draft's assumptions, and how they might facilitate >> malicious RPs or impersonating IdPs. It'd be useful to have a broader sense >> of the protocol at play here, since it sounds like the core goal is for the >> browser to trust the IdP, on the basis that the OS is configured to trust >> the IdP, and that both the user intentionally configured the OS, and that >> the user explicitly confirmed with the IdP. >> >> >> >> I'm not trying to suggest anything nefarious here, but trying to make >> sure we've got a good understanding of the assumptions we make. These may >> be entirely reasonable assumptions (e.g. the OS threat model is explicitly >> addressed as out of scope >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Frefs%2Fheads%2Fmain%2Fdocs%2Fsecurity%2Ffaq.md%23Why-arent-physically_local-attacks-in-Chromes-threat-model&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597866965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QZ1HDw%2FUnVFQZC8ya%2FPtvx8drQNLfSYGJQJTv87%2FSOM%3D&reserved=0> >> in the security FAQ), but it may also reveal complicated interactions that >> could limit the evolution of new protocols (e.g. as Negotiate/Kerberos/NTLM >> did re: HTTP/2 and HTTP/3) or present challenges to some of the work >> regarding privacy sandbox >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromium.org%2FHome%2Fchromium-privacy%2Fprivacy-sandbox&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597876943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZU5f9CA2zdgBXZeJTX%2FSQRHifQTZ2rbWSt7AlCkpC0o%3D&reserved=0>. >> The more documentation you can provide about the protocol interactions, the >> easier it is to evaluate those and be confident the risks are mitigated. >> >> >> >> 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. >> >> >> >> Absolutely, there's a lot of good stuff that can be done. Ideally, >> however, we can pursue that through standards, such as WebAuthN, to help >> ensure users are secure regardless of the OS or IdP. Obviously, we still >> support protocols like Kerberos and NTLM, so it's not that OS integration >> doesn't make any sense - just that it comes with its own set of risks and >> tradeoffs. >> >> >> >> One way of thinking about this is that bringing in some of these >> high-level protocols from the OS - from any OS - is a bit like adding >> third-party libraries >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc.git%2F%2B%2FHEAD%2Fdocs%2Fadding_to_third_party.md&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597876943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mn5%2BXAksutP2iOoMDy6ByuJ592Oav4GiVktfFKvonfo%3D&reserved=0>, >> since it extends the attack surface of the browser. We obviously add 3P >> libraries all the time, so it's not that I'm saying we shouldn't do this at >> all, but it's good to get a sense of how it will work, both technically and >> with web standards, to evaluate the risk. >> >> >> >> One last question, if I haven't overwhelmed you with questions already - >> 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 realize that's probably a huge request, and it >> may be the answer is "No, none of this can change" - but I'm asking now, >> mostly to understand "What do we do if the new protocol has similar >> spec-violating issues like Negotiate/Kerberos/NTLM did", and what the >> options might be to prevent or address that. >> > -- 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/CAN%2BknvV9S33BJthFknN_ujo4RvV6FDt_JAyXv0q4q8ACtx5uHA%40mail.gmail.com.
