A .NET Identity for Developers
Microsoft introduces "Zermatt," a new set of class libraries for the .NET Framework that simplifies identity management.
Microsoft has added a new set of class libraries to the .NET Framework that promises to simplify the way developers address identity management.
The latest tooling is intended to reduce .NET developers' needs to build custom identity plumbing into every new enterprise Web application and Web service. Code-named "Zermatt," Microsoft says the classes introduce a new dev model that factors the authentication and authorization piece out of connected apps.
Zermatt is the latest pillar in Microsoft's identity-management framework, which also includes Windows CardSpace. The latter, a key component of .NET Framework 3.5, lets individuals manage their identities on the Web and across the enterprise. Microsoft released Zermatt -- which is code-named after the Swiss city near the Matterhorn -- for public beta last month.
Developers can use these class libriaries to implement "claims-based identity" in ASP.NET applications and Windows Communication Foundation (WCF) environments. Zermatt can be used in any Web app or Web service that uses .NET Framework 3.5, and can also be used for cross-platform-Java, for example -- claims-aware apps that are based on standard Web services.
At the heart of Zermatt is the claims-based programming model, says Keith Brown, author of the official Microsoft white paper on Zermatt
, which can be found here
. Claims, in the context of Zermatt, are pieces of information about the user that the issuer of that information asserts are valid.
In a claims-aware application, the user presents their identity to the application as a set of claims issued by an external identity system. This external system is configured to give the application everything it needs to know about the user with each request made, along with cryptographic assurance that the ID data comes from a trusted source, says Brown, who is a developer and consultant with Pluralsight LLC, a training provider specializing in Microsoft .NET technologies.
The Zermatt-built, claims-based solutions free a developer from the need to connect to any particular enterprise directory to look up user ID details, Brown explains. Instead, the user requests arrive with all the ID details the application needs to do its job.
"Most developers are not security experts," Brown says. "And generally speaking, they don't like being given the job of authenticating, authorizing and personalizing experiences for users."
Along with the claims model, the Zermatt framework comes with a set of APIs for sorting out identity claims. It also provides developers with a consistent programming experience, Microsoft says, whether they choose to build their apps in ASP.NET or in WCF environments.
Brown gives Microsoft credit for its use of standard protocols in the framework: WS-Federation, WS-Trust and the Security Assertion Markup Language (SAML).
"Zermatt tries to provide the claims-based programming model," Brown says. It determines how to program a claim by providing an interface that extends existing interfaces that ASP.NET programmers already know about, such as IIdentity and IPrincipal, Brown adds.
"Zermatt extends those for IClaimsPrinciple and IClaimsIdentity. Beyond that it provides ways to wire up your applications to get claims through the Federated Authentication module," he explains.
The Developer in the Driver's Seat
Zermatt is a manifestation of Microsoft's ongoing efforts to build an identity metasystem, says Stuart Kwan, program manager of Microsoft's Federated Identity Team. "The Internet wasn't built with an inherent identity layer," Kwan says.
An external identity system, Kwan says, can be configured to provide the application with everything it needs to know about the user with each request, along with cryptographic assurance that the ID data comes from a trusted source. When users arrive at the applications, they bring claims that they grabbed from a Security Token Service (STS), which provides trusted, interoperable security tokens such as Kerberos and SAML.
"Now the app developer is going to write their application to ask for the claims it needs for the user," Kwan explains. "When the IT professionals go to deploy that app, they just link it up to this thing that serves up a security token, which is a signed document that bears these claims."
This model puts the developer in the driver's seat, Kwan says, because the developer defines the information they need to know about the user, instead of having to look into the user's environment and ask, "What info can I get about the user and from where?"
"Coding that into an application can be very challenging," he says. "And when you do it that way, the app gets rigidly attached to the infrastructure and the infrastructure isn't allowed to change, because if you change the way you're representing some data in your enterprise directory, all the apps that made assumptions about the shape of that data start to malfunction."
The thing developers have to keep in mind, Brown adds, is that Zermatt and the claims-aware model don't make the authentication problem go away. "Somebody still has to do authentication," he says. "Someone still has to do those lookups. But by centralizing it, you're making it easier for people to write applications. The assumption here is that over time you're going to have many more Web apps, and it's going to scale better for you. Using this framework, you aren't going to have to figure out how to do authentication every time you write an application."
Brown believes the Zermatt framework and the claims-based authentication model will be a major boon to developers concerned with authentication and authorization. "I think it's going to change the way developers build Web applications," he says.
No release dates have been posted, but a prime-time version of Zermatt is expected by the end of this year.