Federated identity management: Validating users from other organizations

Federated identity management (FIM) is the use of trust relationships between separate security domains (organizations) to provide a seamless authentication for users. This enables the organization to be more agile and efficient while improving user productivity. Developing such trust relationships requires more visibility into partner companies. Emerging standards enable companies with different internal systems to authenticate users between them.

As companies work to drive out costs and gain efficiencies, they are increasingly granting outsiders access to some internal systems, typically through a web-based portal or extranet. Suppliers can gain access to forecasts of your upcoming needs. Customers can see pricing data, production status and estimated shipping schedules. Going the other direction, company employees can use web-based services at benefits companies.

You can apply Identity Management (IdM) software within your own company to reduce security risks, lower administrative costs, and provide better compliance reporting. But what about managing users from other organizations with whom you do business?

That's where federated identity management comes in. In this article, we'll take a look at federated identity management: the extension of Identity Management across organizational security domains.

Federated identity: Beyond the enterprise

Federated identity refers to a situation in which one organization (the Identity Provider, or IdP) verifies the identity of a user, and another organization (the Service Provider, or SP) provides computer services to that user. Examples are an employer (IdP for its employees) and an employee benefits company (SP) with a web-based employee benefits portal. Instead of each organization having to maintain duplicate user identity information, and therefore bear the cost of maintaining it, the employer keeps the user identity information, and the benefits company trusts the employer's authentication. The user is only required to sign on once, not at every website.

We use the principle of federated identity all the time, without realizing it. When you drive a car in another state, the state you're driving in accepts that your home state has verified your identity and your ability to drive. When you use a credit card, the merchant accepting the card trusts that another company has verified your creditworthiness.

In the same way, companies can build trust relationships with each other so that people at one company can use computer systems at another company.

Federated Identity Management goes beyond the technical details of how servers communicate with each other. It's that technology plus business agreements and policies that govern who may access which services, and for what business purposes.

Federated identity systems enable two organizations to agree on a common identity for the user of a computer system, even though privately they may each have different definitions of that user. It's a way of linking together the user's two separate profiles via a common definition that two trading partners agree to share. Furthermore, the shared definition is obscured (hidden) and only used between one pair of IdP and SP services. If it is exposed, it cannot be used to log in anywhere else.

What this means is that a user may sign on and be authenticated by his or her own organization, yet access services provided by another organization without having to sign on again. In contrast, a centralized identity system would require that each of the two organizations trust a third, central repository of user information. In short, federated identity management separates the administration of security from the application, while providing a standard interface for the two to communicate.

How federated identity works

Suppose your employer has contracted with another company to manage travel services. Without federated identity, you would first have to set up a login at the travel company's web site. Each time you visited the site, you would have to log in separately. If you left your employer, they would have to notify the travel company to cancel your account, or you'd still be able to log in there.

With federated identity management in place between the two firms, the first time you visited the travel site the following would happen:

  • First, you would log into your company's employee portal, using your company username and some form of authentication (password, smart card, or even biometrics such as a fingerprint scan.)
  • You would click the link for the travel company portal page.
  • Instead of displaying a login page, the travel company redirects you back to your company's portal, requesting authentication.
  • Because this is the first time you've tried to access the travel company site, your own portal asks for your permission (opt-in) to use your identity with the travel company website. You click Yes.
  • Your company's portal sends you back to the travel company web site, with authentication information attached.
  • Behind the scenes, the travel portal verifies the authentication data transmitted to it.
  • You're granted access to the page you originally requested, without having to log in separately.

Because the service provider is not maintaining its own user accounts for external users, federated identity management transfers the responsibility for identity management (and the resulting cost) to identity providers who are better positioned to fulfill that responsibility. If a user leaves the identity provider organization, the service provider's request for authentication will fail, and the user can no longer access the service provider, all without any maintenance on the service provider's part.

Developing trust within a federation

Central to the working of federated identity is the idea of trust. Liberty Alliance calls it a "circle of trust", and defines it as "a group of service providers that share linked identities and have pertinent business agreements in place regarding how to do business and interact with identities."

But how is that trust established?

The first and most obvious way is through existing relationships with partners, vendors and customers. If your organization already has agreements in place with another organization and you have a history of working together, they're already part of your circle.

Companies with whom you have not done business are vetted using traditional means, such as:

  • Verifying emails, postal addresses, and telephone contacts
  • Using credit agencies or other third party references
  • Membership in relevant industry or trade associations

Clearly in a federated world, companies need to be more transparent, as partners need more visibility into their processes to build trust.

Federation identity standards

Several organizations have been working to define standards for federated identity management. Two of the most visible are OASIS and The Liberty Alliance.

The Organization for the Advancement of Structured Information Standards (OASIS) is a standards body that has technical committees for web services / service oriented architectures (SOA), eCommerce, Supply Chain management, and many other areas. The OASIS Security Services SAML technical committee is charged with "defining and maintaining a standard, XML-based framework for creating and exchanging security information between online partners." The result is Security Assertion Markup Language, or SAML. SAML assertions are XML messages from one organization to another about the identity, attributes, or access privileges of a person.

The Liberty Alliance is a consortium of 150 organizations. Started in 2001 as a response to Microsoft's Passport digital identity solution, its purpose is to develop open standards for federated network identity that are not controlled by any one company. They have published several standards, including Identity Federation Framework (ID-FF) and Identity Web Services Framework (ID-WSF).A key mission of the Alliance is to promote permission-based attribute sharing, so that users have some measure of control over what items of information about them are shared and for what purposes.

Although it looked at first as if there might be a competition between standards to achieve critical mass — as happened with Sony Betamax and VHS in the establishment of videotape standards — that hasn't happened with federated identity standards. Instead, the various standards seem to be converging, and the release of SAML version 2.0 in March 2005 pushed that convergence forward by incorporating input from both the Liberty Alliance and a standard used in educational settings, called Shibboleth.

In the mean time, vendors such as Oracle are offering support for multiple federation protocols to be certain of interoperability. Oracle Identity Management 10g, for example, supports OASIS SAML 1.1, Liberty Alliance, and a Microsoft/IBM standard called WS-Federation. It can even broker or translate between different standards. Oracle COREid Federation is a software package that can be used in-house and also distributed to partners who do not already have an Identity Management solution in place.

The bottom line

Federated Identity Management extends the idea of Identity Management across company boundaries. It decouples identity authentication from providing services. In doing so, it reduces the security risks inherent in duplicated login storage. It also offers a more seamless and productive online experience to users, with features aimed at protecting the privacy of their personally identifiable data

Editor's Picks

Free Newsletters, In your Inbox