What IAM topology lets an identity federation serve service providers that speak OIDC as well as ones that speak SAML?
A broker-based (hub-and-spoke) federation: a central intermediary authenticates users against the IdPs and acts as SAML IdP towards SAML SPs and as OpenID provider towards OIDC relying parties, translating between the protocols.
* A protocol-translating broker: IdPs connect once, applications choose SAML or OIDC. *
Why a broker solves it: in a full mesh, every IdP would have to support both protocols towards every SP. With a hub, each IdP and each application connects only to the broker, in whichever protocol it speaks. The broker:
- receives the authentication result from the IdP (via SAML, OIDC or anything else),
- maps identifiers and attributes into the vocabulary the target application expects,
- issues either a SAML assertion or an OIDC ID token to the application.
This is how many real federations operate: Swiss e-government standards describe broker-based federations in two parallel implementations, eCH-0174 with SAML 2.0 and eCH-0225 with OIDC; Switch edu-ID offers both protocols to Swiss academic services; products such as Keycloak act as such a broker. The trade-off is the one of every hub: the broker sees all logins (a privacy and availability concentration point) and, as an authentication proxy, breaks end-to-end protection between IdP and SP.
Go deeper:
eCH-0174: Broker-based identity federations, implementation with SAML 2.0 — the Swiss e-government standard, written in parallel to the OIDC variant eCH-0225 (in German).- Switch edu-ID: Federation — how a real federation defines trust roots, attributes and metadata for its members.