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 provider).
- 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 in.
- 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 single sign-on.
- In some deployment patterns, federation can eliminate the
administration of IDs or entitlements within applications:
- Domain B trusts domain A to name its own users.
- Domain B does not create its own directory objects to represent 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 plus some RESTful APIs). The most common language/protocol for federated authentication between enterprise applications is SAML 2.0. The most common language/protocol for consumer-facing web sites is OAuth v2.