While the rhetoric between the two has quieted down substantially, the fact that Microsoft is not yet a Liberty member creates the perception that the two organisations are still at odds with each other.
It's a good time to revisit the activity along the battlefront now that the Liberty Alliance has officially shipped its first technical specification. According Microsoft's .Net Platform product manager Adam Sohn "nothing has changed significantly. [Microsoft] communicates regularly [with the Liberty Alliance] and we keep them up to date on what we're up to and we do what we can to find out what they're up to."
Sohn makes an interesting point about why Microsoft has chosen not join the Liberty Alliance. To the extent that any specifications to emerge from the Liberty Alliance are public and free to deploy, Microsoft doesn't necessarily have to join in order to support the specification. "If there's enough demand for it from our customers," says Sohn, "then we can choose to support it [in our products]."
Even so, it's helpful to understand why the rivalry runs deep and what the worst-case scenario could be should Microsoft choose not to support Liberty's current and forthcoming specifications.
Prior to January of this year, concerns existed over the issue of interoperability with the authentication and authorisation underpinnings of Active Directory-based networks. Active Directory is the proprietary directory infrastructure found on networks controlled by Windows-based servers. Authentication is a process that attempts to guarantee that a user (or code) attempting to enter some network realm is not an imposter. Authorisation is the process that grants an authenticated user or code the proper access to certain resources within that realm.
The interoperability concerns, which included criticisms from competitors like Sun and institutions like MIT, centered on Microsoft's deployment of Kerberos and the way in which it allowed for interoperable authentication between Windows-based networks and non-Windows based networks, but not authorisation. Within networks, the authorisation part is typically managed by network administrators through group membership. For example, one way to grant a user access to a directory is to join that user to a group which already has the necessary privileges. Microsoft's implementation of Kerberos came with a license agreement that made it impossible for non-Windows networks to interoperate with Microsoft's group membership technology.
Microsoft's resistance to freely interoperate can be traced back to its need to protect its intellectual property. Microsoft sees Active Directory as a product that gives the company a technological edge against competing directory providers like Novell, and some of the details of that intellectual property are exposed by Microsoft's implementation of Kerberos. According to Sohn, Microsoft doesn't want to foster the cloning of Windows domain controllers. A domain controller is a server (or series of them) that's been designated to run Active Directory for a company. It's no wonder that the original license agreement included the text "Microsoft does not grant you any right to implement this Specification."
Since authentication, authorisation, and group membership management play an important role in the idea of single sign-on as well as inter-organisational connectivity (Web services style), Microsoft's continued resistance to open its walled garden coupled with its rhetoric about Passport set the stage for Sun to give rise to an opposing force -- the Liberty Alliance.
But in January, Microsoft appeared to acquiesce to the pressure over its proprietary implementation of Kerberos and it didn't just release the details of its Kerberos implementation to the Internet Engineering Task Force. According to Sohn, the specification is also free to deploy commercially, academically, or otherwise for the purposes of authentication and authorisation --but not to clone a domain controller. "We provided everything you need to do group membership interoperability," Sohn said. "The stuff that's not part of that has nothing to with Kerberos authorisation. It has to do with Windows machines talking to Windows servers. Where we drew the line is not enabling people to clone our domain controller, which is our intellectual property and that's what this business is all about."
By January, the battle lines had long been drawn and the focus of the debate centered on Microsoft's Passport and the Liberty Alliance's Project Liberty. Hopes were raised that Microsoft would follow the Kerberos disclosure by joining Liberty. It didn't happen. The obstacle, said Sohn, is the Liberty Alliance's membership agreement. "The membership agreement does not adequately describe the scope of the Liberty Alliance's purpose," Sohn told me. "We saw the specification that was released a few hours ago and know it addresses authentication and authorisation. But what if we joined and the organisation changed its [agreement] to extend beyond the currently stated purpose? We may be forced into disclosing intellectual property that we don't want disclosed. We'd like to see the membership modified to address those concerns. At the very least, let's open that up for discussion."
It seems like a fair request, but so far, that apparently isn't happening. As this story was being prepared, officials for the Liberty Alliance could not be reached due to their participation at the Burton Group's Catalyst Conference in San Francisco where Sohn said "federated security is a hot topic."
And that's the question this saga leads us to: What happens if Microsoft doesn't join the Alliance or support the Liberty specification? In that situation, trust brokers like Verisign that might normally be in the business of helping companies manage their trust relationships might get into the business of bridging security technologies between incompatible (security-wise) trading partners.
Sohn said the WS-Security spec that Microsoft co-authored, which now has the support of Liberty members Verisign and Sun, scratches the surface of the problem but more work needs to be done. "The question," asked Sohn, "is how do you automate trust?" While we wait for that question to be answered, Sohn doubts that a service such a Passport would interoperate with Liberty without doing it directly--in other words, without the need for a trust broker. "The spec came out a few hours ago," Sohn said. "I'm sure we have guys back at Redmond reading that thing right now, and we'll see how the specification answers those tough questions."
It appears that we are closer to a solution for single sign-on and identity management. Even if Microsoft declines to join Liberty, the trust brokers will step in to fill the gap.
Sohn also didn't pass up the opportunity to discuss protocol transition, a cool feature that will make its debut in Windows .Net Server. Protocol transition will allow a user or code to gain access to Windows .Net Server-based resources via any one of a number of authentication mechanisms: Kerberos, PKI, SAML, a X.509 digital certificate, etc. According to Sohn, once that comes in, Windows .Net Server will transition that token into a Kerberos ticket for use in the backend. This is plumbing stuff but it's important plumbing stuff because on the backend, you only have to build one security engine.
Microsoft will probably bend in whatever direction its customers want it to. Let me know what you think in the TalkBack below.
