Foreword by Stuart Kwan

In the spring of 2008, months before the Windows® Identity Foundation made its first public appearance, I was on the phone with the chief software architect of a Fortune 500 company when I experienced one of those vivid, clarifying moments that come during the course of a software project. We were chatting about how difficult it was to manage an environment with hundreds, or even thousands of developers, all building different kinds of applications for different audiences. In such an environment, the burden of consistent application security usually falls on the shoulders of one designated security architect.

A big part of that architect's job is to guide developers on how to handle authentication. Developers have many technologies to choose from. Microsoft® Windows Integrated Authentication, SAML, LDAP, and X.509 are just a few. The security architect is responsible for writing detailed implementation guidance on when and how to use all of them. I imagined a document with hundreds of pages of technology overviews, decision flowcharts, and code appendices that demonstrate the correct use of technology X for scenario Y. "If you are building a web application, for employees, on the intranet, on Windows, use Windows Integrated Authentication and LDAP, send your queries to the enterprise directory...."

I could already tell that this document, despite the architect's best efforts, was destined to sit unread on the corner of every developer's desk. It was all just too hard; although every developer knows security is important, no one has the time to read all that. Nevertheless, every organization needed an architect to write these guidelines. It was the only meaningful thing they could do to manage this complexity.

It was at that moment that I realized the true purpose of the forthcoming Windows Identity Foundation. It was to render the technology decision trivial. Architects would no longer need to create complex guidelines for authentication. This was an epiphany of sorts.

Windows Identity Foundation would allow authentication logic to be factored out of the application logic, and as a result most developers would never have to deal with the underlying complexity. Factoring out authentication logic would insulate applications from changing requirements. Making an application available to users at multiple organizations or even moving it to the cloud would just mean reconfiguring the identity infrastructure, not rewriting the application code. This refactoring of identity logic is the basis of the claims-based identity model.

Eugenio Pace from the Microsoft patterns & practices group has brought together some of the foremost minds on this topic so that their collective experience can be yours. He has focused on practical scenarios that will help you get started writing your own claims-aware applications. The guide works progressively, with the simplest and most common scenarios explained first. It also contains a clear overview of the main concepts. Working source code for all of the examples can be found online (https://claimsid.codeplex.com).

I have truly enjoyed having Eugenio be part of our extended engineering team during this project. His enthusiasm, creativity, and perseverance have made this book possible. Eugenio is one of the handful of people I have met who revel in the challenge of identity and security and who care deeply that it be done right.

Our goal is for this book to earn its way to the corner of your desk and lie there dog-eared and much referenced, so that we can be your identity experts and you can get on with the job that is most important to you: building applications that matter. We wish you much success.

Stuart Kwan

Group Program Manager, Identity and Access Platform

Microsoft Corporation

Redmond, Washington

January 2010

Next | Home