Microsoft Corp. has taken a small step in the right direction by agreeing to implement Security Assertion Markup Language 1.0 in its upcoming .Net operating environment. Although Microsoft's announcement was short on specifics, such as the future availability of SAML-enabled .Net security features, the company deserves commendation for this important move toward support for a standard that most of the Web services security industry has long since embraced.
SAML 1.0 is fast becoming the dominant industry standard for federating diverse security environments in support of multidomain Web single sign-on (SSO), role-based access control (RBAC) and other interoperability scenarios. Microsoft's announcement was just one of several events at Burton Group's Catalyst 2002 North America that showed SAML 1.0 has considerable industry momentum and support. At the conference, the Liberty Alliance industry consortium released its Phase One specifications, which it has developed as extensions to the core SAML 1.0 standard. Many Web access management vendors announced their own plans to ship SAML 1.0-enabled products in the next several months.
Microsoft's decision to support SAML showed that even this powerful vendor can't long resist market forces that have been calling for vendors to converge around common Web security standards. Microsoft presented a compelling vision of federated .Net security environments that incorporate, in addition to SAML 1.0, such specifications as Kerberos, Passport, Web Services Security (WS-Security), TrustBridge, X.509 public-key certificates and Extensible Rights Markup Language access-control licenses. SAML 1.0, in Microsoft's grand scheme, will be used primarily as an XML syntax for describing authentication and authorization "assertion" data structures to be interchanged between .Net and other operating and security environments.
Unfortunately, Microsoft is up to its usual habit of playing games with open standards. The vendor announced that it won't be implementing major portions of SAML 1.0, including the standard's Simple Object Access Protocol (SOAP) binding, Web browser profiles or request/response messaging protocol. Instead of placing SAML assertions in the payload of SOAP messages (in compliance with SAML 1.0), Microsoft will place them in the SOAP header, alongside Kerberos tickets and other claims, in conformance with the Microsoft co-developed WS-Security specification.
We should regard Microsoft's federated security architecture as offering just token support for SAML 1.0. It's not clear how, if at all, Microsoft's SAML implementation will interoperate with other vendors' Web services security products. Microsoft won't implement even the minimal set of SAML 1.0 features that would have been necessary for it to participate in the industry demonstration at this year's Catalyst. The vendor's SAML discussion at Catalyst revolved primarily around the standard's role in facilitating federation over the Internet between .Net-based Kerberos domains that implement WS-Security and TrustBridge. Microsoft's single-vendor federation scenario has little in common with the multivendor SSO/RBAC interoperability demonstrated elsewhere at Catalyst. It's purely Microsoft-centric.
Microsoft's business model in the enterprise software market has long revolved around implementing whatever blend of proprietary and open standards can secure market share most quickly in whatever product niche it has targeted. WS-Security is a specification with great promise, and it includes features that will likely be adopted in future versions of the SAML standard, but it is not yet supported in the SAML 1.0-enabled products that other vendors will be releasing soon.
It's disappointing to see Microsoft take this quasi-proprietary tack with SAML 1.0. Let's hope the folks in Redmond realize soon that inadequate, half-hearted SAML support will only make it more difficult for their customers to implement federated, multivendor security environments.
Kobielus is a senior analyst with The Burton Group, an IT advisory service that provides in-depth technology analysis for network planners. He can be reached at firstname.lastname@example.org. The opinions expressed are his own.