In Information Technology, a federated identity is the means of linking together a person’s electronic identity and attributes, stored across multiple distinct identity management systems. The notion of identity federation is extremely broad, and is continuously evolving.
Identity federation involve a large set of user-to-user and user-to-application as well as application-to-application use-case scenarios, at both a browser tier as well as the web services or service-oriented architecture (SOA) tier. It can involve high-trust, high-security scenarios (sensitive data exchange) as well as low-trust, low-security scenarios (e.g. getting a user’s public data).
Identity Federation and Single Sign-On (SSO)
Related to federated identity is the Single Sign-On (SSO) concept, in which a user’s single authentication ticket, or token, is trusted across multiple IT systems or even organizations, allowing the user to perform different actions in these systems (based on each system’s policies).
Identity federation and SSO have similarities as well as key differences. Identity federation enables users to access multiple applications using the same access credentials. This makes access easy, as users do not have to remember a different set of credentials for every application they use. However, the users have to provide their credentials to each one of the applications separately although the credentials used are the same.
On the other hand, SSO enables users to provide their credentials once and obtain access to multiple applications. In SSO, the users are not prompted for their credentials when accessing each application until their session is terminated.
SSO is a subset of federated identity management, as it relates only to authentication and is understood on the level of technical interoperability and it would not be possible without some sort of identity federation.
What’s a Federation?
A federation is a group of two or more trusted business partners with business and legal agreements, including liability restrictions placed on the business partners.
Participation in a federation allows a user from one federation business partner to seamlessly access resources of another business partner in a secure and trustworthy manner, be it directly using a Web browser, using Web Services or accessing a local application integrated to an other business partners application.
This allows end users to easily accomplish the tasks they need to complete cross-company business transactions. This in turn promotes cross-company business in a loosely coupled environment.
Following this concept, a Federated identity is an arrangement that can be made among multiple enterprises that lets subscribers use the same identification data to obtain access to the networks of all enterprises in the federated environment.
Why use a Federated Identity system?
The appeal of federations is that they are intended to allow a user to seamlessly traverse different sites within a given federation. Because of the trust relationships established between the federation participants, one participant is able to authenticate a user, and then act as an issuing party for that user.
Other federation participants become relying parties. That is, they rely on information that is provided about the user by the issuing party, without the direct involvement of the user. In some cases the user may be anonymous to the relying party, for example, due to the different authentication mechanisms and use of third party authentication mechanisms (for instance, in Single Sign-On schemes).
Federation technology is used to:
- Provide a simple mechanism to identify and validate users from business partner organizations and provide them with seamless access to Web sites within that trusted Federation. With identity federation, you don’t need to create custom sign-in code or manage your own user identities.
Instead, users of your application can sign in using a well-known Identity provider (IdP), such as logging in with Google, Amazon, Facebook, or any other compatible IdP you trust, receive an authentication token, and then exchange that token for temporary security credentials that map to permissions to use resources or execute actions in your application.
- Support standards based end-to-end trust and security for applications exposed as Web services between businesses.
- Off load the expensive part of the user management—the cost of user enrollment, account creation, password management and user care—to one business partner (an identity provider). Using an IdP helps you keep your account secure, because you don’t have to embed and distribute long-term security credentials with your application. Everything revolves around the use of the temporary authentication token issued by the IdP.
- Standardize the provisioning of users and attributes to support both user and application based interactions, extending enterprise identity management to inter enterprise identity management.
- Reduce business partners need to manage large sets of user data, including the cost of managing authentication credentials for large numbers of users.
Are there any Federated Identity standards?
Identity federation can be accomplished in a number of ways, some of which involve the use of formal Internet standards, such as the OASIS Security Assertion Markup Language (SAML), the Liberty Identity Web Services Framework and the WS-Federation standard.
Some of these specifications involve open-source technologies and/or other openly published specifications (e.g. Information Cards, OpenID, OAuth or the Higgins trust framework among others). Below is a short description of each the current Federated Identity standards and specifications.
The Liberty ID-FF 1.2 and Liberty Identity Web Services Framework (ID-WSF) 1.1 threads are driven by the Liberty Alliance, an industry consortium of more than 150 companies and organizations that focuses on standardizing identity federation. For more information, go to http://www.projectliberty.org.
Security Assertion Markup Language (SAML)
The Security Assertion Markup Language (SAML) thread is driven by the Organization for the Advancement of Structured Information Standards (OASIS). SAML provides an XML dialect for embedding identity data in an XML message. SAML versions 1.2 and 2.0 are currently used in federation deployments. SAML 2.0 can be looked at as the convergence of SAML 1.2 and the Liberty Identity Federation Framework (ID-FF) 1.1 specification. For more information, go to http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security.
WS-Federation describes how to manage and broker the trust relationships in a heterogeneous federated environment, including support for federated identities, sharing of attributes, and management of pseudonyms.
WS-Federation (Web Services Federation) is an Identity Federation specification, developed by a group of companies: BEA Systems, BMC Software, CA Inc., IBM, Microsoft, Novell, HP Enterprise, and VeriSign.
Part of the larger Web Services Security framework, WS-Federation defines mechanisms for allowing different security realms to broker information on identities, identity attributes and authentication. WS-Federation has been a relatively independent thread that overlaps somewhat with the Liberty Alliance threads.
For more information about WS-Federation, go to http://schemas.xmlsoap.org/ws/2003/07/secext; for more about interoperability of WS-Federation and Liberty ID-FF, go to http://xml.coverpages.org/WebSSO-InteropProfile200505.pdf.
What’s the future of the federated identity standards?
WS-Federation is currently managed by a vendor consortium and lacks the support of an open third-party standards organization such as the Liberty Alliance or OASIS. While the Liberty Alliance and OASIS standards bodies have been working together more closely to align their respective specifications, the WS-Federation authors have chosen to continue on their divergent path for the time being.
Sun Microsystems and Microsoft announced in 2005 specifications that allow interoperability between the WS-Federation and Liberty ID-FF standards for Web single sign-on (SSO). In an effort to head off the divergence of federated identity standards, the Liberty Alliance donated the Liberty ID-FF 1.2 standard to OASIS, the parent body that manages the SAML standard.
In addition, many of the authors of the Liberty specifications began to participate in the OASIS security services technical committee, the panel that develops the SAML standard. The SAML 2.0 specification released early in 2005 was the culmination of this effort.
The one question that surfaces at the time of designing a new system is around convergence. Will there be a convergence of federated identity standards? Hopefully, this article has shined some light on that conundrum. SAML and Liberty increasingly are becoming intertwined. The WS-Federation spec (and the supporting specifications) stands apart, although some interoperability with SAML is available.
Which standard is best?
Broadly speaking, the decision on which federated identity is best sits in two camps: the SAML/Liberty camp and the WS-Federation camp. Some vendors decide to go for SAML (open standard, wider acceptance), some go for WS-Federation (better support and integration tools from companies such as Microsoft or IBM) and some are planning to incorporate all standards.
In the meantime, practical implementation of federated identity becomes a question of business drivers. If there is a business imperative to integrate and manage distributed systems of identity — and that business imperative demands some near-term action, then the enterprise needs to make some hard choices.
The safe bet is a vendor that has stated support for all three standards. Nearly all do. The implementation choices most likely will come down to the use case and if that use case is supporting open standards, then going for SAML 2.0 offers the simplest, cleanest path.