It's not surprising nowadays to see a single company with tens or hundreds of web applications and services, many of which have their own private silo for user identities, and most of which are hardwired to use one particular means of authentication. Developers know how tedious it is to build identity support into each application, and IT pros know how expensive it is to manage the resulting set of applications.
One very useful step toward solving the problem has been to centralize user accounts into an enterprise directory. Commonly it's the IT pro that knows the most effective and efficient way to query the directory, but today the task is typically left up to the developer. And in the face of mergers, acquisitions, and partnerships, the developer might be faced with accessing more than one directory, using more than one API.
In the Microsoft .NET Framework, there are lots of different ways of building identity support into an application, and each communication framework treats identity differently, with different object models, different storage models, and so on. Even in ASP.NET, developers can get confused about where they should look for identity: should they look at the HttpContext.User property? What about Thread.CurrentPrincipal?
The rampant use of passwords has lead to a cottage industry for phishers1. And with so many applications doing their own thing, it's difficult for a company to upgrade to stronger authentication techniques.
What is Zermatt All About?Zermatt is a set of .NET Framework classes; it is a framework for implementing claims-based identity in your applications. By using it, you'll more easily reap the benefits of claims-based systems described in this paper. Zermatt can be used in any web application or web service that uses the .NET Framework version 3.5.
Download : Zermatt Dev. Whitepaper
