Single Sign-On and Federation Protocol

The Single Sign-On and Federation Protocol defines the rules for request and response messages with which a principal is able to authenticate to one or more service providers and federate (or link) configured identities. When a principal attempts to access a service provider resource, the service provider issues a request for authentication to the principal's identity provider. The identity provider responds with a message that contains authentication information, or an artifact that points to authentication information.

Under certain conditions, an identity provider may issue an authentication response to a service provider without having received an authentication request.

The Single Sign-On and Federation Protocol also defines elements for inclusion in the request and response that control the following behaviors:

• Account federation. A principal can choose to federate a configured identity at the identity provider site with a configured identity at the service provider site.

• Account handle. An identity provider can issue an anonymous, temporary identifier to refer to a particular principal during communication with a service provider. This identifier is used to obtain information for or about the principal during federation (with the principal's consent). The account handle is generated by the identity provider during federation.

  ---

  Note –

  This account handle is not to be confused with the handle that can be generated by the service provider after federation using the Name Registration Protocol as discussed in Name Registration Protocol.

  ---

• Affiliation federation. Federation based on group affiliation can be enabled in an authentication request. If enabled, it indicates that the requester is acting as a member of the specified affiliation group. Federations are then established and resolved based on the affiliation, not the requesting provider. The process allows for a unique identifier that represents the affiliation.

• Authentication context. A service provider can choose the type and level of authentication that should be used when a principal logs in.

• Authentication credentials. A principal can be prompted to authenticate with a user name and password, for example, at the behest of the service provider.

• Dynamic identity provider proxying. One identity provider might be 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. For more information, see Dynamic Identity Provider Proxying.

• Identity provider introduction. When an authentication domain has more than one identity provider, a service provider can use this feature to determine which identity provider a principal is using.

• Message exchange. The authentication request defines how messages are exchanged between identity providers and service providers. The particular transfer and messaging protocol used in the exchange (such as HTTP or SOAP) are specified in profiles defined in the Liberty ID-FF Bindings and Profiles Specification. Two of these profiles are:

  • The Liberty Artifact profile relies on Security Assertion Markup Language (SAML) artifacts and assertions to relay authentication information.

  • The Liberty Browser POST profile relies on an HTML form to communicate authentication information between providers.

  See Liberty ID-FF Bindings and Profiles for more information.

• One-time federation. The ability to federate for one session only can be enabled in an authentication request. This feature is useful for service providers with no user accounts, for principals who want 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.