Federation enables applications in different domains to share
information about users.
- Federated domains must have some pre-established relationship, bilaterally
or in a group.
- Information about users is exchanged:
- Identity: Who is this user?
- Authentication: How/when did the user sign in?
- Authorization: What is the user allowed to do?
- Federation enables single sign-on between domains:
- User attempts to access an application in domain A (the service
- The application checks the user's browser to see if he
has already been authenticated. He has not.
- The redirects the user's client (browser) to an
identity provider (IdP) in domain B.
- The IdP in domain B authenticates the user and redirects his
browser back to domain A, along with a cryptographically signed
assertion about his identity and entitlements.
- The application in domain A reads the assertion, validates
the cryptographic signature, and automatically signs the user
- The user is able to perform the same action against other
applications in other domains. If they all trust the IdP at
domain B, he may not be required to sign in again -- hence
- In some deployment pattern, federation eliminates some
- Domain B trusts domain A to name its own users.
- Domain B does not create its own
objects for domain A users.
There are multiple standards for federation, including the security
assertion markup language (SAML -- v1 and v2), WS*Security (mostly
Microsoft) and OAuth (used by consumer web sites like Facebook
and Live.com). The most common language/protocol for federated
authentication between enterprise applications is SAMLv2. The most
common language/protocol for consumer-facing web sites is OAuth v2.
Return to Identity Management Concepts