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