Scenario Validation (Embedded Component (Tableau) )

[LGraber]

It is unclear exactly where to post this to since it is more of a scenario than a comment directly on storage-partitioning but I am picking this repository because I have to pick one. I have tried to outline our scenario, the expecations 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]

Hi @LGraber, thanks for opening this issue. If I understand correctly you don't actually require cookies for authentication with your service, because of the shared identity provider concept, you simply require cookies to "work" in order to save your session state and run the application, correct?

I might not fully understand this sentence:

The only information we need shared across sites is IDP related and seems to be getting addressed

Does that mean that your integration flow does not yet work in Firefox Strict Mode (which does partitioning) or that it does? :)

[LGraber]

Partitioned Storage actually has not shown any problems for us (in my testing). Like I said, I picked a topic but maybe should have picked StorageAccess API since that does not work (and is the option being pushed by Safari).

Our cookie (session and csrf) is used for maintaining an Authenticated Session. If we lose the cookie, we have to ask to re-authenticate. In our cases, this can involve going back to an IDP (which might just work if their cookies are still valid/working). Storage Partitioning right now was the one case that appears to be 'just working' (as outlined in my writeup) but I am continuing to try and test 'corner' cases.

Would you recommend I put this in a different repo?

[johannhof]

It's great to hear that Partitioning is working out well for you! If you encounter any bugs/strange behavior/bad developer experience on Firefox side, we'd love to hear about it on Bugzilla

If you have issues with the Storage Access API specifically, yes, please file them in https://github.com/privacycg/storage-access/. However, note that not all of Safari's restrictions and behavior are necessarily captured in the Storage Access API specification.

For example, Firefox and Edge do not require prior 1st party user interaction to be able to call requestStorageAccess, and (I think both) will allow for requesting storage access without a prompt on the first 5 origins. So that might work better for you. Some of these differences are intentionally left open in the spec, to allow browsers to differentiate on privacy features, but generally we'd like to avoid having a bad developer experience because of it. Again, if you have any specific use cases where the Storage Access API is making things really difficult for you, feel free to open an issue there :)

(cc @johnwilander)

Thanks!

[LGraber]

Thanks! I will copy this over to there. I have tested the StorageAccess API on different browsers and have documented our behavior and the differences in an internal table. Some implementations appear to be able to work with our scenario but others are practically a dead end and it is difficult to tell what to expect because in the end, we want to work in all the browsers our customers use. Thanks for the response and I will continue to test out Partioning