Why does Privacy Sandbox's FedCM explainer say SAML is not well-supported by FedCM?

[bretticus-mc]

Privacy Sandbox states that SAML is not well-supported by FedCM:

As is clear at the FedID CG, there are still a lot of use cases that are not well served by FedCM that we’d like to work on, such as front-channel logout (the ability for an IdP to send a signal to RPs to logout) and support for SAML.

However, my understanding from this FedID CG GitHub Issue is that FedCM is focused only on token delivery. It's up to the IdP to implement the FedCM API Call in a way that would still support the SAML authentication flow on the backend. Is there something I'm missing or misunderstanding that would cause issues for SAML authentication via FedCM?

[judielaine]

Hi, the SAML2 SP initiated Web Browser SSO profile ( see Section 4.1 http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf) is a front channel (eg, redirect or POST binding) protocol.

The current standard for interop, https://kantarainitiative.github.io/SAMLprofiles/saml2int.htmlhttps://kantarainitiative.github.io/SAMLprofiles/saml2int.html requires the redirect binding which includes the SAML request (presumably a unique string if appropriate population of fields occurs) as a "link decoration". The SAML response is a POST.

As long as only 3rd party cookies are a target in privacy flows, SAML protocol continues to work fine and FedCM is meaningless to SAML.

If other privacy work begins to restrict unique "link decoration" and other cross-site connections such as POSTs SAML's protocol is threatened.

The important points to recognize include

• FedCM does not support passing the user to the IdP when the user is not authenticated at the IdP:
  • SAML IdP sessions are usually less than 24 hours, latest NIST has very short sessions before requiring the user to enter credentials again, and
  • there are multiple usecases where the IdP needs to interact with the user, even if the user has an active session, including (force authn, MFA, consent for release of various attributes);
• SAML flows can involve users selecting from thousands of different IdPs, any "selection" function in FedCM is unlikely to support that scale;
• the trust model for browsers (origin and site) is a much broader match than SAML IdPs and RPs - many different IdPs and RPs can be at the same origin;
• control of the site and the security of tld+1 site web server may be very different than the control and security of the IdP.

[scantor]

It isn't just the current standard for interop; SAML's artifact binding (the equivalent to the back-channel code exchange in an OAuth code grant flow) is virtually unused and moving to it is not going to happen. If you break POST, you break SAML.

[judielaine]

And -- i forgot this point -- SAML in use in Higher Ed, Enterprises, and Health Care FREQUENTLY chain IdPs. FedCM will be very hard for the user to authorize all the hops. The hops can be aggregators such as a research application at a university that depends on the large laboratory where the experiment is occurring for auth; the large lab depends on the universities that the researchers are at to provide auth, a university may have a public SAML provider for the entire org, but delgates to schools and the hospital and associated institutes for the final authentication step.

FedCM has poor support for that chain.

[giordanoj]

Hi - thanks for questions/answers here.

Does FedCM intend to support that kind of chaining? Or is that covered via another proposal? Or is the expectation that flow is done away with altogether?