Cookie access needed for customer-configured service requests

[petipp]

Our product is a web application with a significant client-side footprint. It has the ability to connect to HTTPS-based services from the browser if those services are configured using CORS and enable Access-Control-Allow-Credentials.

Current Limitations

Partitioning cookies is part of the solution: it allows a session to be held across the calls to the service and this would allow basic auth to work.

The services only support SP-initiated SAML for SSO:

• The SP-initiated SAML workflow executes in a pop-up (to ensure that the identity provider has access to its first-party cookies)
• After redirecting to the IdP and back, a session cookie is set for the target service and then the pop-up is closed
• The fetch requests made from the application (using CORS as mentioned above) will include that session cookie

The biggest challenge is the inability to change those services (with the software update lifecycle controlled by customers) which makes switching to OAuth not possible and even makes more limited changes (e.g. requestStorageAccess) less feasible.

It seemed like the most promising approach was executing requestStorageAccessFor from the application before launching the pop-up.
However, if it ends up limited to RWS then this will not be sufficient: the domains belonging to the services are the customer's domains (possibly local to their intranet) while our application runs in our own domain.

requestStorageAccessFor abuse

With that in mind, the Abuse concerns for rSAF mention a scenario where a top-level site embeds some code (e.g. through some extensibility/embedding mechanism) and this code triggers the rSAF flow with no knowledge of the top-level site.

The discussions seem to be implying that there are 3 key pre-requisites to allow the embedding to access cookies:

1. the embedded domain must indicate that it wants its first-party cookies
2. the embedding application must agree that the embedded domain should have access to its first-party cookies in this context
3. the user (or their representative, such as a company IT team or pre-configured trusted RWS) agrees that the embedded domain should get access to its first-party cookies

The abuse concern mentioned above implies that it is mandatory that 1 and 2 be established before prompting the user for 3, just to avoid bad associations.

Sidebar: comparison to requestStorageAccess

But let's take a quick look at requestStorageAccess: does it establish both 1 and 2 before prompting? I don't believe so. If reputable-news-site.example includes a library that renders an iframe against we-hate-puppies.com that requests storage access then the news site gets no say in the matter. And clearly in that same situation the user will still attribute the request to the domain in the URL bar even if it isn't explicitly mentioned in the prompt. Is rSAF being held to a higher standard than rSA without much of a benefit?

Analysis of Scenario

Back to the scenario at issue:

1. is clearly covered because CORS configuration from the embedded domain which accepts being called from the specific embedding application and accepts the use of its cookies
2. would be covered if we prompted the user (or via Chrome Enterprise policies)
3. is harder to resolve: code run within the embedding application couldn't really "prove" that it was legitimate which leave us with the initial HTML response which is clearly owned by the embedding domain.

Proposal: Allowed domain list with wildcards

The HTML file or its headers could include a list of allowed top-level domains to allow connections to. The application is responsible for gathering those up and providing them to the browser. Alternatively, can pass a wildcard instead indicating that the application is okay with all rSAF requests.

Open questions

• Would rSAF still need to be executed from a user gesture event? If so, what would it add (given that the user can't be certain that the gesture was somehow associated with the target domain in any way)?

Related

Note that there is an issue tracked for the scenario described here:
https://issuetracker.google.com/issues/281645556