Scenario Validation (Embedded Component (Tableau))

[LGraber]

It is unclear exactly where to post this to since it is more of a scenario but after initially posting on the partitioning repo, I am reposting here as this proposal is currently not satisfying the requirements and so probably will generate more discussion. Here is the link to the other post if anyone wants (privacycg/storage-partitioning#21). I have tried to outline our scenario, the expectations of our customers and end-users and the impact of all of the options currently on the table. Hopefully this issue can be used to have a discussion and I don't have to post on all the repositories?

Background

Tableau is a service which can run as a SaaS offering or via an on-premise, customer managed server installation. Tableau uses cookies primarily for session management. After a user logs in to Tableau, a session is created and a cookie is used to maintain this information (along with a csrf cookie used as part of CSRF protection). One of our primary (not unique) use cases is via embedded analytics where our visualations and experiences are embedded as a component (iframe) inside of a customer site or a third-party application. When cookies stop working, our ability to maintain sessions is broken and our user experience most often degrades into an endless login loop. We hit similar issues during the fixes for SameSite attribute enforcement (which just required updating everywhere we generate cookies) but are trying to make sure that the current proposals take into consideration our customer needs.

Requirements

• Our embedding experience should feel like a native part of the app it is in. That means we should not require re-prompting for authentication and we should not require the user to “accept” that a component service uses cookies.
• A single Tableau tenant ‘site’ can be embedded in many different apps including wiki, chat, portal, or a collaboration app. Those apps are not necessarily all in the same domain as they could themselves be SaaS services (with vanity subdomains) and so do not necessarily have a relationship outside of potentially user identity.
• Many of our embedded customers also use Tableau directly. For them, a common solution to SSO is sharing an IDP between Tableau and the embedding app, like Ping or Okta. With this established, and with CSP frame-ancestors to establish security (ideally), they are able to perform the auth handshake with no clicks / pop-ups, at which point Tableau can generate a session.
  • We are working on alternatives to establish trust with embedding client applications but the end result is still a session (cookie).
  • Customers not able to meet our current SSO experience security requirements can fall back to “Click To Sign In” experience where we launch a popup to do the auth handshake but it is a fallback and not the approach desired by our customers.
• We do not own all layers of the stack between our service and the browser. On premise customers can choose to put load balancers or authenticating proxies between us and the browser. For our SaaS service we have layers of AWS (technically our choice but still limited by their requirements)

Options

We have broken down options going forward and provided insight into each as well as a look at how proposals from the committee might affect them.

• Stop Using Cookies (for embedding) — We have tried to evaluate this using our existing iframe model and also considering a non-framed model (which would have introduced even more security related concerns). This comes with the following concerns:
  • We don’t own the layers between us and the User Agent so it is not even clear that we can do this. Cookies are still a fundamental part of some LBs (https://aws.amazon.com/about-aws/whats-new/2021/02/application-load-balancer-supports-application-cookie-stickiness/). When SameSite enforcement hit we had to work with numerous on-prem customers to deal with issues in their network stack to make things work again.
  • Native elements like ‘img’ tags could not be used without a full scale switch to use src:data encoding. Our images still require auth which is provided for by the session cookie (do not require the csrf header in this path). This is just one example.
  • Session management is a primary use case for cookies. That is what we are using them for. Breaking that ability seems ...
• Keep using cookies but become first-party — via mechanisms like CName cloaking or SSL terminating proxies. Concerns:
  • CName cloaking is being looked at as a ‘hole’ in the current proposals and not a long term solution
  • Configuring SSL terminating proxies for all places we could be embedded is not feasible / scalable for our customers.
  • Any option like this can lead to cookie ‘leakage’ depending on the Domain and Path attributes that are set so it could introduce security issues as it attempts to address others
• Keep using cookies ‘as-is’ — this relies on some of the proposals currently being discussed that we are hoping to chime in on.
  • Partitioned Storage — as demonstrated by Firefox’s implementation and our testing, this seems very promising. The only information we need shared across sites is IDP related and seems to be getting addressed (although how WebID applies to embedded content is not yet clear to me)
  • First Party Sets — This also seems reasonably promising. It requires us to finish up some work for ‘vanity’ urls (in-progress and highly desired) as we would need to identify tenants via subdomains but the main concern is how we can support embedding a single tenant ‘site’ into multiple applications which could be in different domains. It would be odd to put them in the same domain set, especially since multiple would be ‘owners’. Also, Tableau can itself be embedded into with third-party content (also using iframes) so how could we manage all of that?
  • StorageAccess API — depending on the algorithm used, this can work as demonstrated by our testing. However, that is only verifying the ‘hasStorageAccess’ api, which does not require an explicit user interaction (click). The requestStorageAccess API can only work in our ‘Click to Sign In’ scenario and so breaks our seamless SSO requirement, and even then some browser implementations won’t even ask the question if we have never been a first-party.
  • WebID — This is mostly focused on making sure that our integration with IDPs continues to work. I am not sure if falls under the bucket of us continuing to use cookies but is something I am trying to understand how it relates to embedded content using an IDP

Current ‘Conclusions’

We have data that we can share which breaks down the impact of the currently available implementations and our testing of them across different browsers. Our hope is to work / communicate with the working groups to understand what the expectation so that we can continue to meet the requirements of our customers and end users.

[johannhof]

@LGraber Hi, would you have time to join our Privacy CG teleconference tomorrow? This issue is on the agenda and it might be helpful if you could present your findings directly and be available for questions.

Thanks!

[LGraber]

@johannhof Yep. Kris forwarded me the information when we saw it was on the agenda. 9am PST. Will be there. Thanks!

[mpsenn]

I too haven't found an allowed way to authenticate requests for protected <img> and CSS content, in a 3rd party iframe context.

I also corroborate that the StorageAccess API has huge limitations. The Webkit implementation requires an explicit interaction for every page load. So even if a user has granted access, if the user refreshes the page, access is lost.

[hpsin]

@LGraber is it correct to assume that all of these various frames need to fall back to a single auth source? As in, Tableau.example embeds tableauWiki.example, and both make (silent) requests to customerAuth.example to perform auth?

If so, a single storage access request from (tableau.example) to (customerAuth.example) should suffice for all embedded apps.

The problem is that it requires a high degree of non-standardized coordination between you and potentially multiple IDPs in order to get the prompt to trigger (visible interaction between the user and an embed of the customer IDP directly). We have some internal proposals for how to standardize a "prompt=storage" OIDC handshake that specifies e.g. iframe size and parameters to create a user interactable "finish sign in" button. Would that be of interest to you?