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.)
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 email@example.com.