Support chained authentication flows before reducing heuristics and classifications/lists in navigational tracking mitigations

[judielaine]

Chained authentication flows

The abstraction of federated identity includes the principal, an RP, and an IDP (as defined in https://fedidcg.github.io/FedCM/). In enterprise and R & E (research and education) practice there are frequently more parties involved, where an application acts both as an IdP and as an RP.

Current protocols like SAML and OAuth/OpenID Connect allow an link in the chain to translate between acting as and IdP to and RP simply by holding state for one request while making another. The redirect primitive can allow this to be of minimal impact to the principal, the same minimal impact that makes navigational tracking so insidious.

If FedCM is to be a solution allowing for federated authentication while allowing browsers to simply mitigate navigational tracking as opposed to the various heuristics or lists and classifications currently in use, FedCM will need to take into account the network of front channel steps used to support authentication in enterprise, government, research, and education environments.

FedCM and the redirect primitive

FedCM allows the user to signal consent to the browser that one site may provide information to another. Currently, the login screen that pops up when the IdP needs to reestablish state allows redirects. The chains are currently supported in that connection, with FedCM as one link.

While the chain of connections is linear for a user, the architecture is frequently a network. A relying party may perceive the fan of connections it makes to different IdPs. The RP does not necessarily know when an application to which it sends an authentication request depends on making further requests. The upstream systems may not know when down stream parties are acting as representatives of other parties. These connections may be reflected in contractual language, but the technological connections are not transparent.

This makes it difficult for the RP to know all the hops and represent that in requests that will support a single consent step. Some of the current expectations -- such as the user has already visited the IdP -- will be challenging in the existing network.

Why does such chaining exist?

There are three broad use cases for these cross-site chains. An authentication infrastructure element (application acting as both and IdP and RP) may fulfil more than one of these purposes:

1. bridging communities (RPs use one IdP when the source of authentication truth can be at many).
2. translating between protocols and adding claims
3. MFA integrations

Note that a particular user may be encounter combinations of these use cases in a particular flow. Currently the principal is aware of initial relying party, but may not be as aware of the bridges, translations, and assurance applications that make the chain.

See https://aarc-community.org/architecture/ fro an architecture of a "proxy" which may fulfil either or both of use case 1 and 2. See https://duo.com/docs/azure-ca for a specific implementation of use case 3.

The FedCM community group has discussed this complexity a number of times

A concrete example

As a specific example

1. A reading list management application is a relying party to a cloud service that manages library inventory
2. The cloud service is a relying party to the Dutch SURF federation
3. The Dutch SURF federation is relying party to an university's Microsoft Entra implementation
4. The Microsoft Entra implementation is a relying party to Duo Security's second factor offering

In the position between 1 and 2, cloud service provider bridges between protocols (the APIs at the cloud provider need OAuth tokens, the SURF federation uses SAML), removes attributes about the user that the reading list management application has no business knowing, adds authorization as appropriate for API access.

In the position between 2 and 3, the hub federation endpoint allows the university customer of the library service to authenticate users across the Dutch higher ed community into their library resource and support cross institutional educational agreements without the cloud service integrating directly with each on behalf of that customer.

Between 3 and 4 is the "classical" IdP, but it depends on another service to confirm the authentication.

Why front channel?

[DISCLAIMER: this is not my area of expertise but i've discussed with people in medical subject research this requirement.] There are secure research environments where the network is closed except for the https incoming traffic. SAML protocols allow transfer of authentication and authorization over that front channel in a secure manner.

[bc-pi]

In my experience chained authentication flows are indeed quite common.

[judielaine]

A number of chained authentication flows at https://wiki.refeds.org/display/GROUPS/Chained+Authentication+Demos

[philsmart]

The accounts_endpoint is challenging if the IdP does not handle user sessions. There is no way to make front-channel requests to the authenticating authority to see if a session exists.