Since the advent of Web services, and other distributed computing standards for that matter, we’ve been wrestling with the notion of identity and how to manage it. Truth-be-told identity management has been put on the back burning are organization attempt to get their first Web services projects up-and-running. However, as Web services become more pervasive, this is an issue that is getting more attention.

With the increasing interest in identity management, so has risen the need for standards to better define this space. These standards are all aiming at binding together identity management systems within all organization into a unified whole, allowing for everyone to be know to everyone else, securely. To that point, let’s examine the emerging standards, along with notion of federated identity management.

Who Are You?

So, why do we need identity management? It’s the fact that Web services are not for internal use anymore, and those who leverage Web services (consumers), or produce Web services (provider), need to know known to each, else we risk invoking malicious or incorrect behavior, which could cost us dearly. This is clearly the case within trading communities that leverage Web services. Many outside organizations are binding to your services and you to theirs, and the potential for disaster increases, unless you know just who you’re dealing with.

Identity is important in the growth of sensitive data and confidential relationships online. Lacking identities there is no way to provide certain users with access to certain resources.

Today, we use managed identities, including different user names, passwords, and other identifying attributes. The same person may have links to many organizations, including frequent flyer sites, banking sites, employee benefit sites, etc. Perhaps you have a list of user names and passwords in your drawer today.

The number of identities that we have creates a challenge. We’ve all written down user IDs and passwords on sticky notes just to remember them. Moreover, IT organizations find it increasingly difficult to manage the profusion of identity databases, even within their own organization. The problem becomes more of an issue as we extend our reach outside of the firewall, inter-organization. Enter federated identity and potential solution to this problem.

Federated identity, including supporting standards, such as those from OASIS and the Liberty Alliance project are defining mechanisms that organizations may employ to share identity information between domains. While most understand the value of an identity management systems internal to an enterprise, federated identity presents a new set of problems, and an opportunity for solutions.

There are many benefits to employing federated identity solutions including the ability to perform logging and audit functions centrally, reducing costs associated with password reset, and access to many existing heterogeneous application securely.

Standards and Identity

In order to support the notion of Federated identity you need a loosely coupled architecture that allows for the exchange of identity information, in and between entities. Thus, you must all get on the same channel as far as interfaces, messaging, security and content standards, or we have no hope of solving this problem. There are three contenders:

• Oasis and SAML
• Microsoft, IBM, and the WS-Roadmap
• Liberty Alliance

Security Assertion Markup Language (SAML) is an XML framework for exchanging security information over the Internet and enables disparate security systems to interoperate using a single security mechanism, thus providing federated identity management. SAML resides within a system’s security mechanisms to enable exchange of identity and entitlement with other services. It defines the structure of the documents that transport security information among services.

SAML has the following components:

• Assertions and request/response protocols.
• Bindings (the SOAP-over-HTTP method of transporting SAML requests and responses).
• Profiles (for embedding and extracting SAML assertions in a framework or protocol).
• Security considerations while using SAML (highly recommended reading).
• Conformance guidelines and a test suite.
• Use cases and requirements.

SAML provides technology that supports a single sign-on using XML. Using SAML authentication, you can sign-on and receive a SAML authentication assertion as a response to the request. This authentication assertion is simple XML and is transportable using SOAP.

WS-Roadmap is really just a white paper published by IBM and Microsoft outlining a roadmap for building a set of Web service security specifications. WS-Security was their first specification they published.

The WS-Security specification proposes a standard set of SOAP extensions that can be leveraged when building secure Web services to implement confidentiality, or the ability to leverage Web services without having to worry about others getting into your business.

WS-Security is designed as the base for the construction of a wide variety of security models, which includes

• PKI.
• Kerberos.
• SSL.

Moreover, WS-Security provides support for multiple security tokens, multiple trust domains, multiple signature formats, and multiple encryption technologies.

This standard defines three main mechanisms:

• Security token propagation.
• Message integrity.
• Message confidentiality.

Each of these technologies do not provide a complete security solution, and WS-Security is a building block that can be used in conjunction with other Web service extensions and higher-level application-specific protocols to leverage a wide range of security and encryption technologies. You may use these independently (e.g., to pass a security token) or tightly integrated; for example, signing and encrypting a message and providing a security token hierarchy associated with the keys used for signing and encryption.

The importance of leveraging this standard in the world of application integration is obvious, as we seek ways to exchange messages between enterprises with the assurance that others outside the trading partners won’t have access to it. The support for multiple security standards is an added value as well, considering the number of organizations that may be involved and the diverse security technologies that may be in place.

The Liberty Alliance is really a consortium of about 170 companies that built a specification for federated identity management. The idea, at first, was to create a comprehensive federated identify specification. However, last year they also released a new blueprint describing three specifications. You can leverage the specifications together, or separately.

They include:

Identify Federation Framework (ID-FF), which allows single sign-on and account linking between entities with pre-established relationships.

Identity Web Services Framework (ID-WSF), allowing groups of trusted partners to link to other groups, providing control over how their information is shared.

Identify Services Interface Specifications (ID-SIS), which builds a set of interoperable services on top of the ID-WSF specification.

As we move forward with SOAs, and learn to extend them beyond the bounds of our firewalls, the need for identity management technology will increase. Security is sometimes an afterthought when building a SOA, internally, but those looking to extend their SOA outside of the firewall are seeing the need now.