Microsoft has launched a new developer framework codenamed "Zermatt" on July 9th. It is currently in beta, and the first final version is expected towards the end of this year. This framework consists of a comprehensive set of libraries that facilitate the use of "claims" in applications - in Microsoft's words: make them "claims-aware". This greatly simplifies the development of applications that will work within federated environments and the new identity metasystem technology that Microsoft is developing, and will give a push to adoption of the new identity technology. In this short analysis, we take a first look at Zermatt, and also at the context of where it will be used in.
With the release of the first version of Active Directory Federation Services (ADFS), Microsoft has opened up its identity subsystem to enable federated single-sign on between different companies or entities on different domains using the WS-Federation protocol. The ratifications of the WS-* standards through the OASIS body and its adoption by the industry has paved the way for a secure and interoperable web services framework. However, deployment of applications that make use of this new framework has been slow - also because of the fact that it has been difficult for developers to use the features.
Up to this point, developers had to make use of Microsoft's Windows Communication Framework (WCF) to harness those features when writing WS-* claims-aware applications. WCF did not make it particularly easy to make applications claims-aware. With the new Zermatt framework, named after a picturesque Swiss town next to the Matterhorn mountain, developers now have a framework that enables them to easily utilize claims, the essence of identity within the WS-* framework.
In simple terms claims are pieces of information about an identity, asserted by some issuing party, or even the user itself. Currently, user information is kept within an enterprise or application directory. Applications have to authenticate users and fetch required information from the directory server. The new identity metasystem allows for a complete de-coupling of the application from the confines of the environment by outsourcing the authentication and identity information signing to secure token services (STS). This requires an application to set up a trust relationship with one or more STS authorities. The application will then have access to a set of "claims" about the identity of a user - for example the name, email, role(s) within an organisation. A claim could come from a trusted source (STS), or from a source that the trusted source trusts (delegated trust). Regardless where each "claim" comes from, it is up to the application to trust it or not.
This model is a significant improvement, and enterprises can profit from it in several ways. First of all, using this methodology, applications will no longer have to query enterprise application directories in order to get to the identity information - instead, the pieces are provided by other parties. Also, this approach takes federation to a new level, where federated users will not have to be pre-provisioned, as was the case previously within the Microsoft ecosystem, when ADFS was deployed with legacy applications that were not "claims-aware" (in the former case, a "stub entry" had to be created within Active Directory for every external user that would be able to "federate in" from the outside, so that ADFS could create a legacy Windows NT security token upon successful federated log-in).
Another important concept of WS-Trust is the ability for a service to run other services on behalf of another user. This is especially interesting for distributed security critical or high-value transactions. Typically, services run under a service account, hence under a different identity from the users that are accessing it. When work is carried out by these services, it is therefore carried out under the credentials of the service account. In a distributed architecture, this is essential for governance and auditing purposes.
The white paper released by Microsoft, together with the Zermatt software and programming examples also explains how to build a custom STS. The groundwork is all done by the Zermatt library, and therefore allows a developer to concentrate on writing the actual business logic to enable the trust relationships. The documentation hints towards significant new STS features in Microsoft's upcoming next release of ADFS and suggests that the best approach for most organisations is to buy a STS, and not build - however for those who need to build, the framework is there in Zermatt ready to be unleashed.
Business impact
What is the impact of Zermatt for the industry? Within the Microsoft environment, this is an incentive for developers to make their applications claims-aware, and to use the new features that WS-* brings. It is therefore realistic to expect more applications becoming ready for federation in the near future, and an impetus for SOA developers to draw on identity information through WS-*. Although the Zermatt framework is very specific to the Microsoft environment it may be likely to see similar efforts being made on other platforms. Most likely, existing frameworks might be extended to make the processing or claims easier in other environments, and provide foundations to build secure token servers in an easier way than done today. Kuppinger Cole also expects that vendors will soon start shipping their own shrink wrapped STS. As Microsoft is expected to significantly upgrade ADFS in the next release, we also expect opportunities for companies to harness ADFS's customisation and plug-in capabilities to create value-added add-ons, similar to what Omada has done for Microsoft's ILM.
Significant gaps still remain in pure-play WS-*
Brave new world? Should companies jump on WS-* and start redesigning architecture? At this point in time, that would still be risky, whenever access control and GRC (Governance, Risk Management and Compliance) need to be part of the picture. The features and capabilities of WS-* are very promising, yet there is a very significant gap with authorisation and GRC . The existing framework handles federated single-sign on and exchange of identity data very well. However, authorisation is completely unsolved in the protocols, and applications are expected to make their own decision on what and whom to allow. In the past, Microsoft had offered its "Authorization Manager" (AzMan) for adding role-based access control to applications without having to rely in Windows security groups. This approach is pretty much obsolete in a WS-* scenario, and enterprises will currently have to make a very tough choice for a proprietary access control solution from one of the other major vendors in that space. XACML is currently touted to solve this issue in a standardised way, but there is little experience in real-world scenarios. Microsoft itself acknowledges that the lack of a standardised authorisation model is a gap that is left to be filled, but does not work with the industry in order to address the issue.
Another detail - if not gap - is how applications can fetch additional information that they may require about a user, if this information is not contained in the original claim. Within the current model, it is completely up to the claim's issuing authority to make sure that the identity information contained in the claim is complete enough for the application to carry out its work. This pushes the work to the requesting service to do all the look-ups and present all identity data at once. The Liberty Alliance is spearheading efforts to make it easier for applications to access additional data through the ID-WSF standards. Also, the Identity Governance Framework, another initiative of the Liberty Alliance, provides a more structured approach to dealing with identity data in general.
Kuppinger Cole's advice is for enterprises to harness Zermatt in order to prepare their internal applications for claims-based access, but to be aware of current limitations and plan ahead. Currently, authorisation is an unsolved issue, and Microsoft seems to suggest that applications would need to cater for their own authorisation policies and strategies by embedding authorisation decisions in the code that use information provided in the claims. Driving down that road however, one will eventually hit a large wall somewhere on the highway. Externalisation of authorisation is definitely the better solution, but the options for doing so today are not yet perfect. Currently it is possible to externalise policy decisions using proprietary approaches, such as shrink-wrapped access management software. In future, we may see a more broad adoption of XACML, which would address that issue.
Summary
Zermatt is an important contribution to the Microsoft identity ecosystem because it allows developers to easily make their applications and services claims-aware. With the final version expected by the end of the year, many developers will already now familiarise themselves with this relatively simple new programming model. As a result, the amount of claims-aware applications will rise. We also expect more vendors offering secure token services (STS), and some enterprises harnessing the Zermatt framework to build their own specialised STS.
At the same time, there are still considerable gaps with the WS-*, especially regarding authorisation, that enterprises need to be aware of when choosing to use thesm. Although proposals for standards to cover access management and identity governance already exist, Microsoft's position on those standards is unclear at this time.