Our federated future

An analyst clarifies identity management standards, explaining how all options lead to federation.

Federation is the dominant trend in identity management. But many users still aren’t sure what federated ID management is, how it can benefit them or how they can implement it as part of the evolving new data center architecture.

Essentially, federated ID management is a result of the modern world of distributed network services and refers to establishing trust relationships among decentralized security and policy domains. With a federated ID environment, a layer of abstraction is implemented over legacy identity and security domains. Using standardized methods, each domain can share its local identity and security information while retaining its own internal directory, metadirectory, account provisioning and public-key infrastructure services.

Many IT professionals have heard of federated ID initiatives such as the Security Assertion Markup Language (SAML), Liberty Alliance and WS-Federation, but aren’t clear on whether, how and to what extent these specifications overlap or complement one another. They wonder whether the technology is ready to use in their new data center architectures. Rest assured, federated ID deployment is growing rapidly, delivering solid benefits for pioneers even as standards makers work to ease the way toward tomorrow’s implementations.

Standards emerge

The primary federated ID standards vying for a place in your infrastructure are SAML 1.1, Liberty Alliance Identity Federation Framework 1.2 (ID-FF) and Identity Web Services Framework 1.0 (ID-WSF), and WS-Federation 1.0.

While implementing custom-built federated ID environments also is possible, such interfaces aren’t easily extensible to new partners and applications. That’s what one multinational financial services firm found when it built a federated business-to-business ID environment using a proprietary approach. The firm’s federated ID environment, built three years ago, lets employees log on to an internal employee portal and, through that site, access partner Web sites. They do so on a single sign-on (SSO) basis.

“With [the emergence of] SAML, we’ve gotten push back from external partners because our federation approach is proprietary. That has spurred us to implement SAML, which has come up as a top priority,” says a project leader for Web services security at the firm who asked not to be named.

Indeed, with standards development, the number of companies that have built federated ID production and pilot implementations continues to grow. Burton Group estimates many more than 100 federated ID production implementations have launched throughout the corporate world.

Many of these implementations involve SAML-enabled Web access management tools from vendors such as Computer Associates, Entrust, Entegrity, HP, IBM Tivoli, Netegrity, Novell, Oblix, OpenNetwork, RSA Security and Sun. An open source implementation of SAML also is available through www.opensaml.org.

When companies turn to SAML, they do so for internal and business-to-business SSO, but usually in phases, depending on where their needs for federated ID are strongest. “We’re already doing SAML, but only in limited external federation deployments,” says Mike Beach, associate technical fellow at Boeing Shared Services Group in Seattle. Boeing has implemented two business-to-business production deployments of SAML for SSO with customers, plus has several others in discussion.

“The great thing about using the SAML standard is we can provide interoperability even with different vendor products at the end points,” Beach says. “We even have a successful integration with an open source SAML implementation.”

What about Shibboleth?

Liberty-based federations are fewer than pure SAML implementations but are becoming more prevalent. MarviQ, a Dutch application service provider and systems integrator, has implemented a hybrid Liberty/SAML-based federated ID environment for some customers, and within its own intranet. It chose SAML 1.0 as a basis for federated ID. “[However], since [SAML 1.x] only supports transmission of security data, we needed to fill some gaps, such as global logoff. We used parts of ID-FF for that. Currently we are working for one of our customers to get this to comply to ID-FF fully and maybe ID-WSF as well. I find the Liberty specification the most elegant way to implement federated identity systems,” says Jaap Gorjup, lead architect for security and ID management at marviQ in Amsterdam.

Microsoft and IBM are the primary developers of WS-Federation, one of several WS-* specifications the two companies worked on. This specification doesn’t build on SAML 1.x, although it is similar to the SAML and Liberty specifications. WS-Federation addresses the same broad functionality as Liberty’s ID-FF 1.2, including support for multilateral identity federation, account linking, SSO and privacy protection. And, like SAML and Liberty, WS-Federation implements its profiles primarily through browser redirections and a request/reply protocol for exchanging security tokens.

Unlike Liberty and SAML, WS-Federation is agnostic to the tokens – whether its username/password pairs, Kerberos tickets, X.509 certificates or SAML assertions – used for federated security services. This is because WS-Federation references WS-Security and inherits that specification’s support for a broad range of tokens.

But WS-Federation’s road map is uncertain. WS-Federation 1.0 was announced by Microsoft and IBM last July. But these vendors have not announced plans to turn WS-Federation over to OASIS or any other standards group, pending ongoing workshops and interoperability tests with customers.

Standards evolution

The Security Services Technical Committee (SSTC), responsible for ongoing SAML development at the Organization for the Advancement of Structured Information Standards (OASIS), is the principal group defining federated ID standards. The current SAML standard is Version 1.1, which OASIS ratified last September. SAML 1.1 incorporates incremental feature enhancements, clarifications and errata over SAML 1.0, which OASIS ratified in November 2002. Soon after its finalization in the middle of 2002, SAML 1.0 was rapidly embraced and implemented by Web access management vendors.

SAML 1.1, like its predecessor, defines a standard for bilateral SSO among two federated domains: one that authenticates browser-based users and another that controls access to the requested resource. The standard defines a data structure (called assertions), server-side functional entities (called authorities), implementation profiles and a request/response messaging protocol to support this core functionality.

Many, but not all, Web access management vendors have upgraded their products to support SAML 1.1 in addition to 1.0. An important caveat for SAML implementers is a basic assertion-level incompatibility between SAML 1.0 and SAML 1.1 when schema validation is employed. An instance of a SAML 1.0 assertion can’t be validated against a SAML 1.1 schema, because SAML 1.1 uses XML Schema identifiers. The change was introduced to facilitate digital signature processing on assertion data elements. However, most SAML-based products that support both versions can sense which version a particular assertion is using.

OASIS SSTC’s SAML 2.0 development formally got underway last September, and the committee expects a first full draft for industry review in the second or third quarter of this year. SSTC has published its “active work items,” which constitute the likely features of SAML 2.0. This next major SAML version will include improvements based on implementer requests and will tackle some formerly deferred features by integrating most of the features of Liberty ID-FF 1.2. Liberty contributed ID-FF 1.2 to SSTC last November. SAML 2.0 also will include several new features deferred from the development of SAML 1.x.

Liberty Alliance hasn’t stopped evolving its federated ID specifications, but it has deferred all future ID-FF development to OASIS SSTC, in the context of SAML 2.0 and beyond. The alliance now focuses on further development of its ID-WSF 1.0 standard and Identity Service Interface Specifications (ID-SIS), which it released last November. The group hasn’t decided if it will submit these as finished specifications to OASIS or any other standards group.

Vendor support for Liberty’s ID-FF 1.1 specifications continues to grow, and vendors are beginning to outline plans for supporting ID-WSF 1.0 and ID-SIS 1.0. More than 20 vendors have announced support or commitments to implement the Liberty specifications in their products over the coming year. But several significant vendors – most notably IBM and Netegrity – have delayed supporting Liberty until SAML 2.0 is defined and ratified at OASIS.

Where standards converge

All of the federated ID management standards were built on a common core of Web services standards – notably XML, Simple Object Access Protocol and Web Services Description Language. Above that, SAML has largely emerged as the convergence specification. SAML 1.x specifications are the basis for Liberty’s specifications. In turn, Liberty specifications are feeding into the ongoing definition of SAML 2.0 at OASIS. There’s little doubt that SAML 2.0 will provide a fairly complete identity federation framework standard, and that it will be on a fast track for OASIS ratification by year-end.

It’s likely that WS-Federation will figure into an eventual industrywide federated ID framework standard, although it’s not clear whether that will be in the form of a SAML 3.0 or another initiative at OASIS or elsewhere. By the time WS-Federation-based solutions come to market – most likely in 2005 – the number of production SAML and Liberty deployments will be in the hundreds if not thousands. WS-Federation-based environments will have to integrate with a sizable installed base committed to the rival framework.

The worst-case scenario is that Microsoft and IBM hold fast to their separate specifications and in the process polarize the federated ID market for the near future. But even if the standards wars persist, adoption of federated ID will continue to grow for the next several years, at least.

“WS-Federation’s non-convergence with SAML and the Liberty Alliance is not holding up any momentum in the marketplace, in terms of getting federated ID in place,” says Eric Norlin, senior vice president for strategic marketing at Ping Identity and a principal in the SourceID open source ID initiative. “Convergence is not a roadblock to implementation, from what we can see.”

Kobielus is a senior analyst with Burton Group, an IT advisory services that provides in-depth technology analysis for network planners. He can be reached at (703) 924-6224 or jkobielus@burtongroup.com . The author wishes to acknowledge Burton Group colleagues Dan Blum and Gerry Gebel for their assistance with this story.