Our federated future

Standards emerge Standards evolution Where standards converge Three Liberty standards What about Shibboleth? A logical view of SAML 1.x

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."

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.