Federated identity management lets individuals use the same user name, password or other authentication mechanism to perform a single sign-on, and access applications and data hosted by more than one organisation. An employee portal that links a pension fund, savings bank, payroll processing company and medical insurer is a good example of a federated identity management deployment.
Partners in a federated identity management system depend on one another to authenticate their respective users and vouch for their identity and access privileges. Currently, companies must choose between one of three evolving protocols - Security Assertion Markup Language (SAML), Liberty Alliance and WS-Federation - to federate user identities across corporate boundaries. These protocols standardise communications between applications so partners are not forced to adopt the same technologies for directory services, security and authentication. However, interoperability remains a roadblock, because not only the three protocols but also different versions of the same protocol are incompatible.
A new technology called a federation gateway has emerged to provide protocol translation services between corporations that use different federated identity management protocols.
How it works
Central to a federated identity system is the trust relationship between a Web site/organisation that authenticates users (known as an identity provider) and the site that relies on this authentication to provide secure access to a Web application or service (known as a service provider). A federation gateway eliminates the need for an identity provider site and a service provider site to use the same federated identity management protocol and version.
Let's consider how a federation gateway operates at a service provider site, which must process requests from multiple identity providers to access its applications. In our example, Company A is acting as a service provider using the SAML 1.1 protocol to offer its partners federated access to its Web applications. Meanwhile, three partner companies (Companies B, C and D) that require access to Company A's applications will act as identity providers. However, the identity providers have standardised on separate protocols - SAML 2.0, Liberty 1.1 and Liberty 1.2, respectively.
The federation gateway enables Company A's federated identity management system to interoperate with Company B's, C's and D's federated identity management systems because it translates incoming SAML 2.0, Liberty 1.1 and Liberty 1.2 assertions into SAML 1.1 before sending them on to Company A's applications. Conversely, it presents itself to each identity provider using the native federated identity management protocol deployed by the site. In our example, the federation gateway speaks SAML 2.0 to Company B, Liberty 1.1 to Company C, and Liberty 1.2 to Company D.
A federation gateway works in the following way. First, an authorised user from Company C requests access to a secure application at Company A's Web site. The federated identity management system at Company C redirects the user, who has a Liberty 1.1 assertion, to the federation gateway at Company A. The federation gateway verifies the assertion is coming from a trusted partner, creates a SAML 1.1 assertion, and redirects the user to Company A. Upon receiving and verifying the SAML 1.1 assertion from the federation gateway, Company A lets the user from Company C access the requested application without prompting him for a user name and password.
In an environment where federated identity management standards are still evolving, a federation gateway enables companies to deploy federated identity management with the confidence of knowing they can seamlessly connect with their business partners irrespective of protocol.