[Sign In] RP1 embeds content from RP2. Both trust same IDP. SSO required. IFrame used for RP2

[LGraber]

For this example, RP1, RP2, and the IDP are all on different domains and provided by different service vendors. If those service vendors support vanity urls such that the urls can appear to be the same domain, this degrades into a different scenario (and also becomes the target of other privacy protection investigations). We assume that users are employs of RP1 and are not necessarily even aware that RP2 is providing parts of the content when using sites on RP1.

• RP1 -- www.acme.com
• RP2 -- www.myembeddedanalytics.com
• IDP -- www.idp.com

Description of Flow

Acme employee turns on their laptop, opens their favorite browser, and visits the acme employee portal (RP1). They are redirected via either SAML or OIDC flows (doesn't matter) to a login page on www.idp.com (IDP). After logging in, IDP stores a cookie indicating that they have logged in and redirects the browser back to RP1. RP1 completes the SAML/OIDC flow by establishing its own session cookie and then proceeds to load the portal page. On the initial page or on subsequent pages, the content contains resources provided by www.myembeddedanalytics.com (RP2). Those contents are loaded via an iframe. RP2 must also establish the identity of the user and so attempts to follow the SAML/OIDC flows within the context of the iframe. The IDP will detect that the user identity tracking cookie is already set and so simply redirect back to RP2 with the required assertions for the user. RP2 will then setup and maintain its own session cookie and render its embedded content

Even today, this will only work if the IDP allows itself to be embedded. This can be done by not setting the X-FRAME-OPTIONS header to 'deny' or 'sameorigin' (which is considered a security risk for ClickJack attacks) or by using the CSP frame-ancestors header (which is considered a secure path to provide this and recommended approach to prevent clickjack attacks).

Implications of blocking third-party tracking cookies

The IDP's cookie is by definition a third-party tracking cookie. If those are blocked, with no other work, this flow will not work. The IDPs cookie is associated with www.idp.com and will not be available in the context of RP1's iframe. For IDPs that disallow embedding (via X-FRAME-OPTIONS headers), the current workaround is to launch a popup which will load RP1, do the login flow with IDP, return to RP1 and then auto-close the popup while broadcasting a message back to the originating frame to 'refresh'. This solution will also fail once tracking cookies are blocked since the popup frame will have created a session as a top level site and that cookie will not be available in the RP1 frame inside or RP2 (even with CHIPS or anything else)

Further

This case is a fundamental case and requires some solution to securely establish the user identity in the context of RP2, inside of an iframe, without any additional user interaction

[LGraber]

I created this to reference for a proposal I am making for one possible approach (I think there will be many solutions needed and not a single perfect one).

[berilee]

Would there ever be a case where user has multiple accounts with the same IDP, and they want to use one for RP1 and another for RP2?