The Identity Federation Framework (ID-FF) specifies core protocols, schema and concrete profiles that allow developers to create a standardized, multiple-vendor, identity federation network. These include the following:
Users can choose to stop their account federation.
Service providers with federated accounts communicate the type and level of authentication that should be used when the user logs in.
Federation based on group affiliation can be enabled in an authentication request. If enabled, it would indicate that the requester is acting as a member of the affiliation group identified. Federations are then established and resolved based on the affiliation, and not the requesting provider. The process allows for a unique identifier that represents the affiliation.
When one identity provider is asked to authenticate a principal that has already been authenticated by a second identity provider. In this case, the first identity provider may request authentication information from the second identity provider on behalf of the service provider. Proxy behavior can be controlled by indicating a list of preferred identity providers, and a value that defines the maximum number of proxy steps that can be taken. Proxy behavior is defined locally by the proxying identity provider, although a service provider controls whether or not to proxy.
This feature provides the means for service providers to discover which identity providers a principal uses. A principal can be an organization or individual who interacts with the system. This is important when there are multiple identity providers in an identity federation network.
Defines how service providers can obtain name identifiers assigned to a principal that has federated in the name space of a different service provider. When a principal that has an identity federation relationship (and therefore a name identifier) with one service provider requests access to a second service provider site that requires a name identifier, the second service provider can use this protocol to obtain the identifier. It allows the requesting service provider to communicate with the second service provider about the principal even though no identity federation for the principal exists between them.
Enables a service provider or identity provider to register with each other a new name identifier for a principal at any time following federation.
The ability to federate for one session only can be enabled in an authentication request. This is useful for service providers with no user accounts, for principals who wish to act anonymously, or for dynamically-created user accounts. It allows for one-time federation, rather than a one-time name identifier for a session.
Users can choose to federate different service provider accounts.
The protocol that defines the process that a user at a service provider goes through to authenticate their identity with an identity provider. It also specifies the means by which a service provider obtains an Authentication Assertion from an identity provider to allow single sign-on to the user. Two types of Single Sign-On exist which either the identity or service provider can implement:
SOAP-based Single Sign On and Federation Protocol, which relies on a SOAP call from provider to provider. This is primarily the Browser Artifact SSO profile.
Form POST-based Single Sign On and Federation Protocol, which rely on an HTTP form POST to communicate between providers.
The protocol used to synchronize the session log-out functionality across all sessions that were authenticated and created by a particular identity provider. Two types of protocols exist which either the identity or service provider can implement:
SOAP-based Single Log-Out Protocol relies on asynchronous SOAP messaging calls between providers.
HTTP Redirect-based Single Log-Out Protocol