What is Federated Identity Management?

Federated identity management means linking and using the electronic identities a user has across several identity management systems.

In simpler terms, an application does not necessarily need to obtain and store users’ credentials in order to authenticate them. Instead, the application can use an identity management system that is already storing a user’s electronic identity to authenticate the user—given, of course, that the application trusts that identity management system.

This approach allows the decoupling of the authentication and authorization functions. It also makes it easier to centralize these two functions in the enterprise to avoid a situation where every application has to manage a set of credentials for every user. It is also very convenient for users, since they don’t have to keep a set of usernames and passwords for every single application that they use.

Some Background Information

Single sign-on (SSO) started it all. Organizations needed a way to unify authentication systems in the enterprise for better management and security. Single sign-on was widely adopted and provided a solution for keeping one repository of usernames and passwords that could be used transparently across several internal applications.

Service-oriented software kicked off the next wave of change. Organizations wanted to open APIs in their software so partners and independent developers could use them. Managing authentication and authorization for entities looking to consume these APIs was obviously a challenge.

Social media moved things even further. Various platforms spread far and wide on a plethora of devices, and many applications were built on top of those platforms. Now we have countless apps and services hooked into Twitter, Facebook, and LinkedIn.

The problem? How to bring together user login information across many applications and platforms to simplify sign-on and increase security. The solution? Federated identities ...

There are three major protocols for federated identity: OpenID, SAML, and OAuth.

OpenID

OpenID is an open standard sponsored by Facebook, Microsoft, Google, PayPal, Ping Identity, Symantec, and Yahoo. OpenID allows user to be authenticated using a third-party services called identity providers. Users can choose to use their preferred OpenID providers to log in to websites that accept the OpenID authentication scheme.

The OpenID specification defines three roles:

• The end user or the entity that is looking to verify its identity
• The relying party (RP), which is the entity looking to verify the identity of the end user
• The OpenID provider (OP), which is the entity that registers the OpenID URL and can verify the end user’s identity

The following diagram explains a use case for an OpenID scenario:

Security Considerations

OpenID had a few interesting vulnerabilities in the past, for example:

• Phishing Attacks: Since the relying party controls the authentication process (if necessary) to the OpenID provider, it is possible for a rogue relying party to forward the user to a bogus OpenID provider and collects the user’s credentials for the legal OpenID provider.
• Authentication Flaws: In March 2012, three researchers presented a paper that highlighted two vulnerabilities in OpenID. Both vulnerabilities allow an attacker to impersonate any user to a website if the website doesn’t properly check whether the response from the OpenID provider contains a properly signed email address.

SAML

Security Assertion Markup Language (SAML) is a product of the OASIS Security Services Technical Committee. Dating from 2001, SAML is an XML-based open standard for exchanging authentication and authorization data between parties.

The SAML specification defines three roles:

• The principal, which is typically the user looking to verify his or her identity
• The identity provider (idP), which is the entity  that is capable of verifying the identity of the end user
• The service provider (SP), which is the entity looking to use the identity provider to verify the identity of the end user

Security Considerations

• A group of researchers presented a paper in 2011 where they used an XML Signature Wrapping vulnerability to impersonate any user.

OAuth

OAuth is another open standard. Dating back to 2006, OAuth is different than OpenID and SAML in being exclusively for authorization purposes and not for authentication purposes.

The OAuth specifications define the following roles:

• The end user or the entity that owns the resource in question
• The resource server (OAuth Provider), which is the entity hosting the resource
• The client (OAuth Consumer), which is the entity that is looking to consume the resource after getting authorization from the client

Security Considerations

• A session fixation vulnerability flaw was found in OAuth 1.0. An attacker can fix a token for the victim that gets authorized. The attacker then uses the fixated token.
• OAuth 2.0 was described as an inherently insecure protocol since it does not support signature, encryption, channel binding, or client verification. The protocol relies entirely on the underlying transport layer security (for example, SSL/TLS) to provide confidentiality and integrity.

This table explains the major differences between the three protocols:

Other Protocols

There is a growing number of other federated identity management options. Here are a few examples.

Higgins: Higgins is a new open source protocol that allows users to control which identity information is released to an enterprise.

Windows CardSpace: CardSpace is Microsoft new identity metasystem that provides interoperability between identity providers and relying parties with the user in control. This protocol is retired though and Microsoft is working on a replacement called U-Prove.

MicroID: MicroID is a new identity layer to the web and microformats that allow anyone to simply claim verifiable ownership over their own pages and content hosted anywhere.

Liberty Alliance: Liberty Alliance is a large commercially oriented protocol providing inter-enterprise identity trust. It is the largest existing identity trust protocol deployed around the world.

Here is a quick summary of federated identities.

Conclusion

In a world with increased interconnectivity between hybrid systems, protocols, and devices, federated identity management tools seem to be here to stay. Although managing federated identity is much more convenient for users who don’t have to remember so many different usernames and passwords, it comes with a security price. However, proper implementation of OAuth, SAML, OpenID, or any other federated identity protocol adds convenience without extra threat surface.

For an updated article comparing OpenID Connect vs SAML 2.0 vs OAuth 2.0, please click here.

References

• http://www.authenticationworld.com/Authentication-Federation
• http://saml.xml.org/saml-specifications
• http://en.wikipedia.org/wiki/Federated_identity
• http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
• http://cve.mitre.org/cve
• https://www.usenix.org/conference/usenixsecurity12/breaking-saml-be-whoever-you-want-be