GSA logs on to standards battle
Connecting state and local government leaders
One of the more interesting wrinkles to the General Services Administration's use of the Security Assertion Markup Language for its E-Authentication initiative is that, by putting its weight behind SAML, it chose one side in what appears to be an emerging standards battle.
Why is that? SAML is a one of two emerging approaches for tackling what is called federated identity management'the ability to share authentication and authorization credentials across different organizations, or between organizations and individuals citizens. There is also a groundswell of support behind another approach, actually a collection of Web services standards, called WS-* (pronounced WS-star).
SAML is overseen by the Organization for the Advancement of Structured Information Standards and is backed by such heavyweights as Oracle and Sun Microsystems. But Microsoft and IBM have been putting their weight behind WS-*.
"They are competing standards. I think if you talk to Microsoft, they would say that they are solving a slightly bigger problem than SAML is. I think the OASIS people would also say that they are solving a slightly different problem," said Jackson Shaw, senior director of product management for Quest Software, which makes a tool for helping Federated Active Directory ingest SAML tokens.
When we spoke with David Temoshok, director of identity policy and management at GSA's Office of Governmentwide Policy, he stressed that GSA did not want to lock the federal government into one company's product line, and this is why the agency has been backing the Liberty Alliance's interoperability testing, which ensures that SAML products from different companies work with one another.
While WS-* could become too Microsoft-centric, SAML, does have its own weaknesses. One of the main ones is a split in vendor support between the older, somewhat widely-implemented version 1.1 of the standard, and the newer version 2 of SAML.
Northrop Grumman systems engineer Erik Bowman told us that "SAML 2.0 protocol doesn't go back to version 1.1. So the products that support 1.1 and before are not necessarily compatible" with those running 2.0. So if you have, say, IBM Tivoli Access Manager running SAML 1.1 at one end and Sun Microsystems Access Manager running SAML 2.0 at the other, you might have to do some hard-coding for them to recognize each other's SAML assertions, Bowman said.
And it is anything that a sure bet that those companies supporting 1.1 will jump to version 2.0 For instance, Juniper has a line of virtual private networking appliances that support 1.1 though the company hasn't yet committed to supporting 2.0 (though the company is considering it, Rich Campagna, product line manager at Juniper, told us).
NEXT STORY: Balancing rights at both ends of the pipe