Identity federation is federating an entity's identity to facilitate single sign-on or cross-domain single sign-on. It's an approach of authenticating a user across multiple sites within a company (intranet) or across independent and disparate domains (extranet) using open standards. Here is an example to elucidate the concept in layman's term. As the Internet age is slowly creeping into day-to-day life, users typically end up managing a humungous number of accounts/passwords of various websites. Some are frequently accessed and some seldom used. If all these accounts are federated using the Identity Federation concept, the users can use their frequently used account to access their less visited ones without remembering all the passwords. It's a paradigm shift.
Federation protocols
There are many federated identity protocols which are based on open standards. The most popular ones are Liberty Identity Federation Framework (ID-FF 1.1), Liberty Identity Federation Framework (ID-FF 1.2), Liberty Identity Web services Framework (ID-FF 1.1),SAML 1.0, SAML 1.1 and SAML 2.0. All the liberty frameworks are defined by Liberty Alliance, an industry-wide consortium formed to define the laws of federated identity, which exchanges user-centric data among the circle of trust or within trusted partners. The Security Assertion Markup Language (SAML) protocols are the most widely adopted mechanisms to exchange the authentication and authorization data over platform independent XML framework. All the Liberty Identity frameworks are based on top of SAML 1.X or 2.0 protocols. New open source protocols like Higgins, policy frameworks like Internet2 Shibboleth and decentralized frameworks like OpenID are also used as means of federating Identities.
Terminology
Service provider: Any site/organization becomes a service provider when exchange of metadata information between the service provider and the user chosen identity provider is successful. Service providers bank on the identity providers for user information. Some identity federation implementations also refer to service providers as application sites.
Identity provider: If one assumes an identity federation framework to be based on client-server architecture, then the identity provider can be classified as a server. It is the trusted partner site. It takes part in federation with all service providers within the circle of trust and pushes user-centric data and authentication related information during single sign-on. Some identity federation implementations also refer to the identity provider as an authority site, a site responsible for user authentication, token creation and passing that information onto the service providers using any of the federation protocols.
Metadata: Metadata contains the definition and description of a partner site involved in federation within a circle of trust. It encompasses single logout and single login URLs. It also contains public key certificates for the trusted partner sites to judge the validity of the messages received. A correctly signed message signifies a legal communication from any participating partner within the circle of trust.
User attributes exchange: This is an exchange of user-related data during communication between the identity provider and a service provider. All application sites invariably need attributes for the authenticated user. Identity providers can be configured to push user-related data during SSO. Typical user attributes are first_name, last_name, personal_email, etc.
Dynamic user provisioning: If a user accesses any of the application sites for the first time, the application site would automatically create a new user account and activate it. This phenomenon is called as dynamic user provisioning and for this auto-activation to happen the user should be an authenticated user at the identity provider. Details required to create a new user would be provided by the identity provider using the user attributes exchange.
SSO: Single sign-on facilitates a user to access all the trusted partner sites within the circle of trust without logging in to the individual sites. The application site recognizes a local user once the Liberty assertion generated by the authority site is received and verified by it. Henceforth a user need not provide local identity to log in to any application site. Federated credentials of the user are enough within the circle of trust. SSO is typically achieved by either setting some object in the session or temporary cookie in the browser.
SLO: Single logout terminates or logs out the user from all the active sites. An active site is a trusted-partner site, which the user has accessed within the SSO session.
How does cross-domain SSO work?
1. To build a circle of trust a network has to be built between the service providers (SPs) and the identity provider (IDP). A valid request for federation from an SP to an IDP will only get generated if the IDP recognizes the originator of the request. An exchange of metadata between the IDP and a particular SP typically qualifies inclusion of both parties in the circle of trust. Metadata describes a trusted partner. The metadata typically contains public key certificates, key descriptors for message signing, a URL for the SSO service, a URL for the SLO (single logout) service, etc.
2. Once a federation initiator is within the circle of trust, the user can initiate an SSO request. The user typically provides a return URL for the IDP to redirect the user once the SSO is complete. A successful completion of SSO marks the linkage between the federated user ID and the local user ID for that specific application. SSO is achieved either by session tokens or cookies and is implementation specific. Once a user is federated from a specific application he/she can access any of the other federated applications within the circle of trust using the federated user id. Some financial organizations might need additional security as a consequence of their stringent policies. In that case, on top of SSO, these organizations can opt for another security layer. It might be as simple as userid/password or even biometric authentication.
3. Now let's take up a case where the user is successfully federated through an application we'll call A1 and attempting to log on to a separate application, A2. Both applications are hosted by an SP within the circle of trust. Before we proceed let's take a step backward. When the IDP communicates with the SP, they abide by a protocol. The protocol (typically called federation policy) suggests that some attributes have to be pushed by the IDP to the SP during SSO. These attributes can be user attributes like names or e-mail addresses or even non-readable attributes like pseudonyms.
The user provides the federated user id and password to log on to application A2. Now, as the federation was done through application A1, A2 will not be able to recognize this user though the user has been authenticated by the IDP. In this case some identity federation products automatically create a new account (the userid and password being the activation attribute pushed by the IDP to this SP during SSO) in application A2 for this user and log the user in. This process is called automatic activation or automatic provisioning.
5. The user can initiate a request for SLO after his/her work has been accomplished. The user has the option to terminate the federated session before initiating a single logout.
Pre-initiation of SSO
When a user requests a protected resource in an application, the application needs to know whether a request for an SSO should be initiated. The application first checks whether the browser is an IDP/service/protocol-enabled browser to initiate the SSO. If a cookie is present in a specified sub-domain, the application detects it and qualifies the browser as an IDP/service/protocol-enabled browser. This cookie is identified as the introduction cookie or federation cookie (dependent upon the product) in identity federation jargon. The cookie is set by the SP on certain conditions. These conditions are implementation or product specific. If the cookie is not found, a request for reading the introduction cookie is initiated by the SP to the IDP. If the cookie is present, then the application initiates an SSO. Different products have different ways of implementing the introduction cookie, hence a detailed description of the federation cookie is beyond the scope of this article.
Summary
The identity federation realm is not a new concept though it has picked up a lot of steam recently with the introduction of SAML interoperable products by various vendors. In this article I have tried to bring out the essential features and concepts of identity federation without delving too deep into the implementation specific details. As users we need to be familiar with the concepts before we bother with the implementation. 