Overview
[Starting with the .NET Framework 4.5, Windows Identity Foundation (WIF) has been fully integrated into the .NET Framework. The version of WIF addressed by this topic, WIF 3.5, is deprecated and should only be used when developing against the .NET Framework 3.5 SP1 or the .NET Framework 4. For more information about WIF in the .NET Framework 4.5, also known as WIF 4.5, see the Windows Identity Foundation documentation in the .NET Framework 4.5 Development Guide.]
.gif "WIF Logo")
Identity Challenges
Most developers are not security experts and many feel uncomfortable being given the job of authenticating, authorizing, and personalizing experiences for users. It’s not a subject that has been traditionally taught in computer science curriculum, and there’s a long history of these features being ignored until late in the software development lifecycle.
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 led to a cottage industry for phishers. And with so many applications doing their own thing, it’s difficult for a company to upgrade to stronger authentication techniques.
A Better Solution
One step toward solving these problems is to stop building custom identity plumbing and user account databases into every new application that comes along. But even developers who rely on a central enterprise directory still feel the pain of mergers, acquisitions, and external partnerships, and may even be blamed for poor performance that is actually due to another application bogging down the directory with inefficient queries. The claims-based solution described in this paper avoids asking developers to connect to any particular enterprise directory in order to look up identity details for users. Instead, the user’s request arrives with all of the identity details the application needs to do its job. By the time the user arrives with these claims, the user has already been authenticated, and the application can go about its business without worrying about managing or finding user accounts.
Factoring authentication out of applications leads to many benefits for developers, IT pros, and users. Simply put, there are less user accounts for everyone to manage, and the resulting centralization of authentication makes it easier to upgrade to stronger authentication methods as they evolve, and even federate identity with other platforms and organizations.
The topics in this section will help you, as a developer, to understand the claims-based identity model and take advantage of it using Windows® Identity Foundation (WIF), the new framework from Microsoft that is focused on identity.
What is Windows Identity Foundation?
WIF 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 guide. WIF can be used in any Web application or Web service that uses the .NET Framework version 3.5 SP1 or later.
WIF is just one part of Microsoft’s Federated Identity software family that implements the shared industry vision for an interoperable Identity Metasystem. Federated Identity comprises four components: Active Directory® Federation Services (AD FS) 2.0 (previously known as “Geneva” Server), Windows® CardSpace™ 2.0 (previously known as “Geneva”), Windows Azure Access Control Services, and WIF. Together, these four components form the core of Microsoft’s new claims based access platform. You can refer to the Windows Identity Foundation Web site at the Security Developer Center on MSDN for more information about WIF as well as the other three components. The white paper “Introducing ‘Geneva’” also provides an overview on the full set of Geneva technologies. For an introduction to creating applications using WIF, see Programming Windows Identity Foundation (https://go.microsoft.com/fwlink/?LinkId=210158) by Vittorio Bertocci (published by Microsoft Press). As of this writing, WIF, AD FS 2.0, Windows Azure Access Control Services, and the Beta 2 release of CardSpace™ 2.0 are available for download.
The topics in this section talk about the claims-based identity model, what problems it can solve, and how you can use Windows® Identity Foundation (WIF) to take advantage of it.