Steps for choosing the right federated identity standard for your company

Federated identity management (FIM) is designed to solve the single-sign-on problem associated with the secure exchange of user data among cooperating organizations, either within an enterprise or among partners, suppliers and customers through extranets.

In both scenarios, users need multiple passwords for multiple accounts, which are expensive to manage and generate a disproportionate percentage of all help desk calls.

An automaker that wants to establish an inventory management portal for dealerships is a good example of an extranet FIM deployment. The manufacturer doesn't want the responsibility or liability of managing a directory of user accounts for dealership employees. Using a federated system, the manufacturer depends on each of the dealerships to authenticate its respective users and vouch for their access and privileges to the inventory management portal. Using standards-based technology, the FIM system enables the dealerships to exchange identity data with the manufacturer without needing to adopt the same technologies for authentication and security.

Therein lies the dilemma for enterprises. Currently, three different FIM protocol standards are available to companies, and each of these is incompatible with the others. These standards are SAML, Liberty Alliance and WS-Federation. Until a single standard emerges and deployments are migrated to this harmonized protocol, IT departments can expect SAML, Liberty Alliance and WS-Federation to coexist.

In a climate where federation protocols are still evolving, how can an enterprise select the right standard? To answer that question, you first need to understand how these three standards came to be. Here's a brief history.

SAML

Security Assertion Markup Language (SAML) was the first industrywide standard created to enable FIM. In 2002, SAML was approved by the Organization for the Advancement of Structured Information Standards (OASIS). SAML is an XML security standard that enables cross-domain authentication and authorization and single sign-on. SAML 1.0 specifies message formats for conveying authentication, attributes and authorizations of users from one site to another. However, it isn't session-oriented and doesn't support global logout, which logs out a user to all sites he is currently visiting.

Despite its limitations, the U.S. government's e-Authentication program has standardized on SAML 1.0. This past summer, SAML 2.0 was released. The new version unifies the single sign-on capabilities of Version 1.0 with the identity federation framework developed by the Liberty Alliance in SAML 1.1.

Liberty Alliance

The Liberty Alliance Project is an alliance of more than 150 companies, nonprofit and government organizations committed to developing an open standard for federated network identity that supports all current and emerging network devices.

The Liberty 1.1 protocol (now called ID-FF 1.1) was designed to address the deficiencies relating to real-world usage of SAML 1.0, such as global logout, the exchange of site metadata and other issues. This specification has been deployed by early adopters in the human resources industry and by some mobile operators. Later, the alliance released a similar standard based on SAML 1.1 called Liberty Identity Federation Framework 1.2 (ID-FF 1.2).

WS-Federation

In a parallel, but less open effort, BEA Systems Inc., IBM, Microsoft Corp., RSA Security Inc. and VeriSign Inc. released a specification called Web Services Federation (WS-Federation) in 2003. WS-Federation, along with WS-Trust and WS-Policy, forms a framework for requesting and issuing security tokens with identity federation capabilities. This specification defines mechanisms to allow different security realms to federate by allowing and brokering trust of identities, attributes and authentication between participating Web services.

WS-Federation is currently managed by a vendor consortium and lacks the support of an open third-party standards organization such as the Liberty Alliance or OASIS. While the Liberty Alliance and OASIS standards bodies have been working together more closely to align their respective specifications, the WS-Federation authors have chosen to continue on their divergent path for the time being.

In an effort to head off the divergence of FIM standards, the Liberty Alliance donated the Liberty ID-FF 1.2 standard to OASIS, the parent body that manages the SAML standard. In addition, many of the authors of the Liberty specifications began to participate in the OASIS security services technical committee, the panel that develops the SAML standard. The SAML 2.0 specification released earlier this year was the culmination of this effort.

Choosing the right standard

Choosing the federated identity standard that's best suited for your enterprise requires careful consideration of several key factors. Here's a four-step process designed to help IT decision-makers assess each FIM protocol and how it maps to their company's requirements.

1. Long-term viability: Viability is determined by the environment in which you plan to deploy FIM. For example, you may want to support SAML 1.1 in order to federate with partners you know are using this protocol. However, you should also look beyond your near-term requirements and consider the importance of supporting global logout and other features, such as user-ID masking, with your current and future partners. It's possible to acquire technology today that supports multiple protocols.

2. Security: This is a paramount concern. Since FIM standards govern access control, a system compromise can be catastrophic. One of the first principles of security is transparency, namely, a system is truly secure only if everyone knows exactly how it works and no one knows how it can be compromised.

The most effective process for achieving this level of transparency is through open review and participation from the industry at large in the development of a specification. One can argue that the relevant community in this case would be technology experts employed at various stakeholder organizations (vendors, customers, integrators), who are encouraged to participate based on their organizations' ability to own and therefore use the standard.

An open membership with a clear intellectual property policy that's reasonable and nondiscriminatory as well as royalty-free is considered necessary for such participation. Closed memberships and vague promises of licensing only serve to stymie industrywide participation. Lack of such policies imply that the standards coming out of such bodies represent and recognize only the contributions of a narrow segment of the industry.

The fact that a standards body's membership is dominated by large and established technology providers is no guarantee of reliable security.

In summary, consider the makeup of the governing body that oversees the development of a FIM specification and its track record of openness or lack of openness.

3. Interoperability: The software industry as a whole has made significant progress on this front. The pendulum has clearly swung from feigned attempts at operating system interoperability via application programming interfaces to the current realization by most vendors that interoperability facilitates widespread deployment of a technology.

To this end, look for a FIM standard that's supported by transparent interoperability programs. These should clearly spell out static conformance requirements for implementation and document the requirements and procedures to achieve certification.

4. Longevity: Finally, consider the longevity of a standard. In this regard, there is growing industry momentum for the most mature FIM protocol, SAML 2.0, to emerge as the de facto industry standard. The tighter interoperability between the Liberty Web-services protocols and the latest version of SAML appear to support this trend. It remains to be seen how this development will affect the evolution of WS-Federation.

Conclusion

Given the fact that the three leading FIM protocols are likely to coexist for some time, enterprises should select the standard best suited to their needs based on the four-step process described above.

Atul Tulshibagwale is CEO and co-founder of Trustgenix Inc., a developer of federated identity management software in Santa Clara, Calif.

Copyright © 2005 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon