Federated Identity Management

Identity management and SSO initiatives are not only beloved by end users afflicted with password fatigue, they're just the ticket to help tighten security and aid in compliance by maintaining identity throughout a transaction flow. Recent advances in federation--the agreements, standards and technologies that render identity and entitlements portable--should make extending authentication across multiple domains less of a hard trek. But before you sign on, realize that essential security standards are maturing at an uneven rate, particularly in the Web Services arena.

In addition, consider how realistic it is to extend SSO (single sign-on) across all your organization's application types, given that browser-based apps continue to grow in popularity and the Web services-based SOA has become the strategic application-delivery model of choice. Adopting any new strategy when requisite standards are incomplete, current standards aren't universally accepted, and legacy applications still must be accommodated makes for a devilishly complex infrastructure.

Many organizations apparently are willing to risk it.

NETWORK ACCESS CONTROL
Immersion Center

NEWS | REVIEWS | BLOGS | FORUMS TUTORIALS | STRATEGY | MORE

WHERE IT BEGINS

We're seeing a growing demand for federation across several vertical industries, with multiple enterprises federating with more than 50 partner organizations, a far cry from the typical one or two more common a couple of years ago. Notably, many, though not all, of these early adopters are looking to replace proprietary mechanisms with standards-based products.

Further, federations that serve tens of millions of users are emerging outside the telecom industry, previously the only vertical boasting deployments of this scale. Organizations publicly talking up their federation projects include American Express, Boeing, Harvard University, Hewlett-Packard, Phillips and Sun Microsystems.

Governments have also made significant federation investments in recent years. Although the E-Authentication initiative--the federation portion of the U.S. E-Gov program--has not been as successful as many had hoped, it does establish federation as a strategic goal. Federation is also a key technology for e-government activities in Denmark, Finland, the Netherlands, Norway, the United Kingdom and other European countries. The Fidelity Project, a consortium of European telcos, is planning a federated identity-management (IdM) system based on the work of the Liberty Alliance.Community federations also are moving beyond the automotive industry, though automakers have the most mature community federation in operation, serving more than 250,000 users, representing 30,000 supply-chain participants in 96 countries. The automotive federation hub, operated by Covisint, provides a number of benefits, including managing business agreements and SLAs, sharing of 400-plus applications, SSO across applications, routing access requests to the appropriate targets, and provisioning access across the community.

Other industries are recognizing the value of having third-party intermediaries handle such complex tasks as brokering trust arrangements, routing messages, and handling protocol or assertion translations. At the Burton Group Catalyst Conference in July 2006, for example, the energy industry discussed its program, which has entered pilot stage with a small number of participants and a production deployment is planned for later this year.

Federation also received a high-profile boost from Bill Gates at the 2006 RSA Security Conference keynote. To paraphrase, Gates said that for the trust ecosystem to be successful, it must be "totally federated." He added that federation is a key component of an identity metasystem, in which multiple identity systems can interoperate. Not surprisingly, federation figures prominently in Microsoft's product plans: Active Directory Federation Services (ADFS), introduced last year, is based on WS-Federation, and Microsoft says it will release a module that supports WS-Trust around the time that Longhorn server ships.

Continue Reading This Story...

TALE OF TWO STANDARDS

Clearly, if federation is to scale as proponents expect, standardization is vital. And indeed, standards and specifications for identity federation are relatively mature. Unfortunately, development of Web services security standards is another story.

In 2002, IBM, Microsoft and partners introduced a vision for Web services security, commonly referred to as WS-*. It included a number of protocols and specifications intended to make Web services secure, composable and interoperable. The first version of WSS (Web Services Security), released in April 2004, covered the basics of message security and the format of identity tokens.

But it wasn't until October 2005 that the critical components WS-Trust, WS-SecurityPolicy and WS-SecureConversation were submitted to the new OASIS WS-SX (Web Services Secure Exchange) technical committee. Version 1.0 of WS-SX is not expected until midyear.

The federation community, however, had the opposite problem: A plethora of standards and specifications are available to address SSO, account linking and other aspects of browser-based applications. The industry has largely consolidated around SAML (Security Assertion Markup Language) 2.0 and WS-Federation after dabbling in alternatives, including SAML 1.0, SAML 1.1, Liberty ID-FF and Shibboleth.Enterprises that put off deployments waiting for SAML 2.0 are now moving forward, as the latest version of this standard becomes more widely available in commercial products. In "Federation Product Market Segments," page 95, we show how the market for browser federation tools is segmented. Most vendors have either added federation technology to their existing Web access management products or created a standalone federation offering. Only a few have adopted a dual strategy, delivering products in both categories. And keep in mind that there is a long list of other product categories, such as XML security appliances, that support a segment of browser and/or Web Services standards.

Bottom line, integrating Web services and browser applications is still tricky. IT groups must be prepared to navigate a shifting standards landscape and keep up with emerging frameworks, such as Higgins and CardSpace.

When users from collaborating organizations must access applications residing in partner sites, federation enables SSO across security domains, reducing the administrative burden and providing sharable infrastructure services. Keep in mind, however, that federation standards shift some identity administration responsibilities between partners, as shown in "Demonstrating the Possibilities," page 96. We can't overstate the importance of business agreements that establish accountability and liability--the foundation for establishing trust and assurance for the federation.

LET ME COUNT THE WAYS

There are many reasons to implement federation, but accomplishing SSO to reduce user name and password combinations when navigating multiple security domains is cited most often. Registering users prior to accessing partner sites is another burdensome process that may be remedied through federation. Enterprises can let users bypass the registration step by preloading necessary attributes before a user first accesses the partner site.Cost savings is a significant federation driver as well: A standardized, reusable infrastructure that can accommodate multiple associates and applications beats multiple proprietary, one-off systems all day long. As noted earlier, we've seen enterprises use federation services to connect with more than 50 entities.

Federation provides the framework to implement very discrete privacy-preserving features, especially in federation specs developed by Liberty Alliance and now contained in SAML 2.0. Federation can be configured to limit the amount of personal data shared among organizations, to avoid violating privacy laws or regulations. In addition, users can be given some control over the sharing of identity attributes for certain interactions with partner sites.

SECURITY LAGS BEHIND

You knew there had to be a catch, right?

Although Web services permit enterprises to create interoperable services-based applications in any language on any platform, the original definition of the Web services framework didn't include a built-in security model. Early implementers compensate by using SSL to protect communications among service endpoints, but SSL does not provide the granularity and flexibility required for more advanced Web services scenarios.If SSL is inadequate, what's an implementer to do? WS-Security, or WSS, provides some relief. The OASIS WSS Technical Committee defined and standardized a core specification for securing SOAP (Simple Object Access Protocol) messages, plus several extensions for integrating user or service identity information within SOAP messages.

For example, WSS profiles define how to incorporate SAML tokens in Web services requests; this enables the identity of the requestor to be retained throughout the transaction flow instead of using service accounts as intermediaries. This aspect of WSS profiles can enhance the auditing of an application environment while preserving SSO for the user. See more on advances in "WSS: The Next Steps".

WHITHER SECURITY?

Given that WSS is needed to retain IdM information in Web services requests, what products can make that happen? Unfortunately, the relative immaturity of the standards and market fragmentation mean there's no easy answer to this question; many, many products support part or most of the WSS profiles and other federation protocols. To illustrate how fragmented the market is, Burton Group defines six categories of vendors:

A considerable amount of consolidation has already occurred in the Web services security market, and we expect additional mergers and acquisitions in the next two years as Web services deployments increase and demand picks up. And, to add to the confusion, WS-SX is getting ready to enter the picture.

MIDNIGHT AT THE OASIS

The Web Services Trust (WS-Trust) specification builds on WSS and forwards IdM by defining methods for issuing, renewing and validating security tokens and mechanisms for assessing and brokering trust relationships. But federation--and WSS as it relates to SSO and securing Web services messages--does not cover the full spectrum of security standards for browser or Web services apps.

Another piece of the puzzle is represented by the OASIS WS-SX Technical Committee. WS-SX was formed in late 2005, and a version 1.0 standard is expected later this year. Three specifications are included in the WS-SX work.The first, WS-Trust, builds on WSS and defines methods for issuing, renewing and validating security tokens, as well as mechanisms for assessing and brokering trust relationships. Like WSS, WS-Trust allows use of existing technologies, such as X.509 public-key certificates, SAML assertions, rights expression language licenses, Kerberos shared-secret tickets, XCBF (XML Common Biometric Format) objects, even password digests.

WS-Trust defines an extensible framework and flexible syntax with which IT can implement various security mechanisms. Because WS-Trust builds on WSS, it supports the ability to broker trust through credentialing by defining a specification for creating an STS (Security Token Service). An STS can be used within and across trust domains, supporting heterogeneous implementations, because it can issue a range of security tokens, which are then used to broker trust relationships across different domains. This flexibility allows the token service to support scenarios where direct trust, direct brokered trust or indirect brokered trust exist. Notwithstanding its name, however, WS-Trust does not provide services or protocols for establishing or revoking trust relationships themselves.

WS-SecureConversation creates shared security contexts by using credentials for message integrity, confidentiality and authentication. A shared security communication is established for the life of the message exchange.

Finally, WS-SecurityPolicy is a framework for policy assertions. It imposes conditions and restrictions on formats defined by WSS and allows messages that are exchanged to be examined for adherence to policy.

Even though WS-SX is not yet formally standardized, some vendors have implemented portions, particularly WS-Trust, in current products. These include IBM, Memory Experts and Ping Identity. Open-source projects, such as CredEx, Higgins, Project Tango and others, are also supporting or plan to support WS-Trust.LOTS OF BALLS IN THE AIR

Making federated IdM work requires a delicate balancing act, especially as multiple technologies and standards, from browser federation to WS-SX, are currently evolving. Fortunately, federated IdM, based on standards such as SAML and specifications like WS-Federation, are mature enough to replace most proprietary authentication systems between existing partners--which makes life somewhat easier.

The optimists among us will see positive forces at work: Because browser federation standards follow the same loosely coupled model ingrained in the SOA concept, federation implementations can bridge browser and Web services hybrid scenarios, and there is progress on the standards development front to finish a version 1.0 standard for WS-SX. Just don't take your eyes off the prize. To stay ahead of the curve, IT must continuously assess the state of the market and readjust architecture goals to keep pace.

Gerry Gebel is a vice president and service director with Burton Group. Write to him at [email protected].

WSS: The Next StepsIn February 2006, OASIS released version 1.1 of the WSS specifications. Version 1.1 is backward-compatible with 1.0 but also brings some important changes and updates to the original specification, including support for SAML 2.0 and signature confirmation in SOAP Message Security 1.1; see " WSS Advances," below.

Because identity flows with all messages, WSS permits enterprises to maintain the identity of the service requestor throughout the transaction or message chain, unlike with SSL. This identity information is inserted using the standard extensions described below. The most commonly used are the Username and SAML token profiles.

In addition to carrying identity information, message payloads also can be protected by using the SOAP Message Security profile, which outlines a standard way to apply encryption or digital signatures to message content.

This means enterprises have more tools at their disposal to implement layered security for Web services applications: SSL verifies service endpoints, WSS token profiles incorporate user identity to provide SSO and basic authorization, and SOAP Message Security protects data as it moves through intermediaries in the transaction chain.

Another important benefit to implementing WSS profiles surfaces when the discussion turns to audit logs. Having user or service identity information as part of each SOAP message will let enterprises capture a more granular view of events in a Web services application. Service accounts (super-user or high-privileged accounts) are commonly used by database, Web access management or other servers to access back-end resources, in lieu of true delegation. But service accounts make it difficult to track usage or events by individual user, giving implementers of Web services another reason to prefer WSS profiles.0