Federation is making it easier to maintain authority across multiple domains. But essential security standards are maturing at an uneven rate. We weigh the risks and rewards of federated ID 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.
Many organizations apparently are willing to risk it.
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.
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.
Autor(en)/Author(s): Gerry Gebel
Quelle/Source: Network Computing, 22.01.2007
