[blink-dev] Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome
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
Re: [blink-dev] Re: Native support of Windows SSO in Chrome
Answer inline. Sasha and Greg, feel free to correct me or add more things if you want. On Fri, Sep 24, 2021 at 1:27 AM Yutaka Hirano wrote: > I have some questions. > > - Is the proposal that Chrome detects such a redirect and sends an > authentication request to IDP? > Browser detects the access of IDP URL(https://login.microsoftonline.com) and appends a cookie which gets from the OS to that request. > - Is there at most one IDP for a profile? / > - How is IDP registered to Chrome? > IDPs are registered with the OS. And the browser gets both IDP urls (see CloudApPlatformWin::ReadOrigins <https://chromium-review.googlesource.com/c/chromium/src/+/3147471/10/content/browser/net/cloud_ap/cloud_ap_platform_win.cc#399>) and cookies from the OS. > > Thanks, > > On Fri, Sep 24, 2021 at 6:18 AM Owen Min wrote: > >> +people who may be interested in this. >> >> On Thursday, September 23, 2021 at 12:21:51 PM UTC-4 Sasha Tokarev wrote: >> >>> Hi all, >>> >>> I have a proposal to integration with Windows SSO in Chrome. >>> >>> Currently Windows has ability to join device to cloud identity, like >>> AAD, MSA. When a device is joined to a cloud identity provider (IDP), it >>> would be great if I’m as a user do not need enter credentials, when I’m >>> using a service, which uses IDP where my device is joined to. I’m consented >>> to have single sign on (SSO) when I joined the device, and trust IDP to >>> protect my identity and do not allow an authorized access. If I do not >>> trust, I should not join my device. Additionally, sometimes web resources, >>> that I’m accessing to as a user, are owned by organization where I work or >>> study. Hence, an organization administrator should be able to manage access >>> to such resources based on the quality of my device, e.g., prevent access >>> if the device doesn’t make malware scans or doesn’t have latest security >>> patches etc. >>> >>> Edge has this feature built in, in Chrome we must use a special >>> extension >>> https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji >>> >>> While using extension works, the built-in experience is better, as we >>> have with Windows Integrated authentication. >>> >>> In high level it should work like this, if I’m accessing to a resource, >>> from a joined device. >>> >>>1. *Resource* (e.g., www.mywork.com) will redirect me for the >>>authentication to the cloud identity provider( >>>https://login.microsoftonline.com). The request will have a redirect >>>URI that IDP will use to return a token. >>>2. *User agent* (Chrome) will detect this navigation and call an OS >>>API for producing a crypto-protected SSO cookies, which has device and >>> user >>>information. This cookie will be appended to the request as a header or >>>cookie. >>>3. *Cloud identity provider* ( https://login.microsoftonline.com ): >>> 1. Detects presence of the SSO cookies, validates them by >>> checking signature, and authenticates the user and device. >>> 2. Validates that the supplied redirect uri is registered for >>> this application. >>> 3. Validates if the resource owner (enterprise admin or user) >>> authorizes access to the resource. >>> 4. Applies consent policy and ask consent if needed, for example >>> enterprises, when they own the resource can pre-consent access by >>> their >>> employees. Note, It is responsibility of IDP to ensure that only >>> authorized >>> and consented applications can access users’ identity. >>> 5. Read device identity, and checks the state of device, that >>> reported out of band by device management system. >>> 6. If all checks are fine, the IDP redirect back to the resource >>> with a token. >>>4. *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. >>>5. *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 th
[blink-dev] Re: Native support of Windows SSO in Chrome
+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. > >1. *Resource* (e.g., www.mywork.com) will redirect me for the >authentication to the cloud identity provider( >https://login.microsoftonline.com). The request will have a redirect >URI that IDP will use to return a token. >2. *User agent* (Chrome) will detect this navigation and call an OS >API for producing a crypto-protected SSO cookies, which has device and > user >information. This cookie will be appended to the request as a header or >cookie. >3. *Cloud identity provider* ( https://login.microsoftonline.com ): > 1. Detects presence of the SSO cookies, validates them by checking > signature, and authenticates the user and device. > 2. Validates that the supplied redirect uri is registered for this > application. > 3. Validates if the resource owner (enterprise admin or user) > authorizes access to the resource. > 4. Applies consent policy and ask consent if needed, for example > enterprises, when they own the resource can pre-consent access by their > employees. Note, It is responsibility of IDP to ensure that only > authorized > and consented applications can access users’ identity. > 5. Read device identity, and checks the state of device, that > reported out of band by device management system. > 6. If all checks are fine, the IDP redirect back to the resource > with a token. >4. *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. >5. *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 > -- 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/bc1fb9ba-2951-4d59-aec1-aed2e88fd584n%40chromium.org.
