Identity Standards Rely on Trust Among Companies

 
 
By Cameron Sturdevant  |  Posted 2005-08-22 Email Print this article Print
 
 
 
 
 
 
 

Opinion: To succeed, federated identity products and identity-based Web services need true interoperability.

The Liberty Alliance Project, a consortium that advocates for federated identity standards and identity-based Web services, last week announced the results of the first SAML 2.0 interoperability tests.

Ill come back to the whys and wherefores of the tests in a moment. But the most important outcome of the tests likely has more to do with ensuring interoperability among organizations that adopt federated identity products than between the products that were actually tested.

IT managers who are currently implementing federated identity projects tell me that arranging the legal and procedural relationships—the human part of federated identity—is actually more significant and more challenging than putting the technology in place.

Extending trust to another entity—be it a parts supplier, bill processor, billing department or fleet dispatcher—creates risk as well as efficiency. Nothing in the Security Assertion Markup Language tests just conducted by the Liberty Alliance will help senior management balance the scales between risk and payoff—not that the Liberty Alliance is making such a claim.

By issuing an announcement that eight companies essentially made the SAML grade, the Liberty Alliance is saying that organizations that choose to trust partners are much more likely to get technology that will support that decision.
Thats an important step down the federated identity path, and its one that IT managers should pay close attention to.

Coming back to the tests themselves, it appears that the Liberty Alliance is making significant progress toward its goal of achieving technical interoperability. We will leave aside, for the moment, that the tests are conducted in a very insulated environment. Most schoolchildren would likely welcome the ability to do a "dry run" test, to have one-on-one meetings with test officials while testing is in progress and to retain sole control over the release of their grades.

According to a Liberty Alliance spokesperson, no one who came to the test failed.

So, one conclusion we can reach is that the SAML 2.0 specification is still at a delicate stage of commercial implementation but appears to support interaction among different vendors products (given enough tender, loving care). Not a bad place to be in the process. More vendors will have a chance to participate in the next conformance event, slated to take place in Tokyo in November. (The dry run will likely be held in late October, for those who like to be superprepared.)

Click here to read more about SAML 2.0. The tests I referred to at the beginning of this column were hosted by the IEEE-Industry Standards and Technology Organization and held in Piscataway, N.J., last month. During the tests, vendors were asked to demonstrate interoperability with one or more of Libertys specifications, including Identity Web Services Framework Version 1.1 and SAML 2.0 OASIS specs.

Since the combination of technologies covered by these specifications is fundamental to providing Web services and asserting attributes and authorization information, passing the tests shows that, at a basic level, the products actually can talk to one another.

Now we come back to the human side of creating a trusted relationship between two organizations: The importance of interoperability to federated identity comes down to finger-pointing. Or, more specifically, a reduction in the amount of finger-pointing. If IT managers can implement products that actually conform to the standards they purport to conform to, federated identity projects stand a much better chance of success.

More than most IT undertakings, federated ID projects get few chances for a "do over." Failed attempts at coupling, especially when tried-and-true (although, quite possibly, more expensive) procedures are already available, could spell death for attempts to get companies to use federated tools.

Hopefully, tests like these will accelerate the pace of the technology and enable companies to implement tools that tip the risk-versus-benefit scales in favor of greater productivity.

Peter Coffee returns to Epicenters Sept. 5. Technical Director Cameron Sturdevant can be contacted at cameron_sturdevant@ziffdavis.com.

Check out eWEEK.coms for the latest news, reviews and analysis in Web services.
 
 
 
 
Cameron Sturdevant Cameron Sturdevant is the executive editor of Enterprise Networking Planet. Prior to ENP, Cameron was technical analyst at PCWeek Labs, starting in 1997. Cameron finished up as the eWEEK Labs Technical Director in 2012. Before his extensive labs tenure Cameron paid his IT dues working in technical support and sales engineering at a software publishing firm . Cameron also spent two years with a database development firm, integrating applications with mainframe legacy programs. Cameron's areas of expertise include virtual and physical IT infrastructure, cloud computing, enterprise networking and mobility. In addition to reviews, Cameron has covered monolithic enterprise management systems throughout their lifecycles, providing the eWEEK reader with all-important history and context. Cameron takes special care in cultivating his IT manager contacts, to ensure that his analysis is grounded in real-world concern. Follow Cameron on Twitter at csturdevant, or reach him by email at cameron.sturdevant@quinstreet.com.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel