How does an identity federation work, and what is its prerequisite?
The subject is redirected from the relying party to the identity provider, authenticates there, and the IdP sends an authentication confirmation to the RP, which then manages a session with the subject. The prerequisite is mutual trust between IdP and RP.
* Redirect, authenticate, confirm, then a session. The relying party never sees the credentials, only the signed confirmation. *
The flow forms a triangle between subject, IdP and RP:
- The subject tries to access the RP.
- The RP redirects the subject to the IdP (in web protocols, an HTTP redirect of the browser).
- The subject authenticates at the IdP.
- The IdP issues an authentication confirmation (an assertion or token) that reaches the RP, usually carried back by the subject's browser.
- The RP accepts the confirmation and starts session management with the subject.
The RP never sees the credentials; it only sees the signed confirmation. That only works because the RP trusts the IdP to have authenticated properly, and the IdP trusts the RP to be a legitimate consumer of its assertions. Establishing this mutual trust (exchanging keys and metadata, agreeing on attribute semantics) is what setting up a federation mostly consists of.
Go deeper:
SAML (Wikipedia) — the classic federation protocol; its web-browser SSO profile is exactly this redirect flow.- OpenID Connect (Wikipedia) — the newer identity layer on OAuth 2.0 that implements the same triangle with tokens.