Web Services

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 burner as organizations 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 increased interest in identity management so too has risen the need for standards to better define this space. These standards all aim to bind identity management systems within an organization together into a unified whole, allowing for everyone to be known to everyone else, securely. To that point, let's examine the emerging standards, along with the notion of federated identity management.

Who Are You?

So, why do we need identity management? Web services are not for internal use only anymore, and those who leverage Web services (consumers), or produce Web services (providers), need to be known to each other, 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 organizations. The problem becomes more of an issue as we extend our reach outside of the firewall, between organizations. Enter federated identity and a potential solution to this problem.

Federated identity, including supporting standards such as those from OASIS and the Liberty Alliance project, is a defining mechanism that organizations may employ to share identity information between domains. While most understand the value of an identity management system 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, cost reductions 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, we 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)
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
This is really just a white paper published by IBM and Microsoft outlining a roadmap for building a set of Web services security specifications. WS-Security was the 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 include:

• 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 does not provide a complete security solution; WS-Security is a building block that can be used in conjunction with other Web services 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: we seek ways to exchange messages between enterprises with the assurance that those outside the trading partners won't have access to them. 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.

Liberty Alliance
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 identity specification. However, last year they also released a new blueprint describing three specifications. You can leverage the specifications together, or separately.

They include:

• Identity Federation Framework (ID-FF): Allows single sign-on and account linking between entities with pre-established relationships
• Identity Web Services Framework (ID-WSF): Allows groups of trusted partners to link to other groups, providing control over how their information is shared
• Identity Services Interface Specifications (ID-SIS): Builds a set of interoperable services on top of the ID-WSF specification

As we move forward with service-oriented architectures (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 an SOA internally, but those looking to extend their SOA outside of the firewall are seeing the need now.