As an application designer or developer, imagine a world where you don't have to worry about authentication. Imagine instead that all requests to your application already include the information you need to make access control decisions and to personalize the application for the user.
In this world, your applications can trust another system component to securely provide user information, such as the user's name or e-mail address, a manager's e-mail address, or even a purchasing authorization limit. The user's information always arrives in the same simple format, regardless of the authentication mechanism, whether it's Microsoft® Windows® integrated authentication, forms-based authentication in a Web browser, an X.509 client certificate, or something more exotic. Even if someone in charge of your company's security policy changes how users authenticate, you still get the information, and it's always in the same format.
This is the utopia of claims-based identity that A Guide to Claims-Based Identity and Access Control describes. As you'll see, claims provide an innovative approach for building applications that authenticate and authorize users.

Who This Book Is For

This book gives you enough information to evaluate claims-based identity as a possible option when you're planning a new application or making changes to an existing one. It is intended for any architect, developer, or information technology (IT) professional who designs, builds, or operates Web applications and services that require identity information about their users. Although applications that use claims-based identity exist on many platforms, this book is written for people who work with Windows-based systems. You should be familiar with the Microsoft .NET Framework, ASP.NET, Windows Communication Foundation (WCF), and Microsoft Visual C#®.

Why This Book Is Pertinent Now

Although claims-based identity has been possible for quite a while, there are now tools available that make it much easier for developers of Windows-based applications to implement it. These tools include the Windows Identity Foundation (WIF) and Microsoft Active Directory® Federation Services (ADFS) v2. This book shows you when and how to use these tools in the context of some commonly occurring scenarios.

A Note About Terminology

This book explains claims-based identity without using a lot of new terminology. However, if you read the various standards and much of the existing literature, you'll see terms such as "relying party," "STS," "subject," "identity provider," and so on. Here is a short list that equates some of the most common expressions used in the literature with the more familiar terms used in this book. For additional clarification about terminology, see the glossary at the end of the book.

relying party (RP) = application
service provider (SP) = application
A relying party or a service provider is an application that uses claims. The term "relying party" arose because the application relies on an issuer to provide information about identity. The term "service provider" is commonly used with the Security Assertion Markup Language (SAML). Because this book is intended for people who design and build applications, it uses "application," or"claims-aware application," instead of "relying party," "RP," "service provider" or "SP."

subject = user
principal = user
A subject or a principal is a user. The term "subject" has been around for years in security literature, and it does make sense when you think about it—the user is the subject of access control, personalization, and so on. A subject can be a non-human entity, such as printer or another device, but this book doesn't discuss these scenarios. In addition, the .NET Framework uses the term "principal" rather than "subject." This book talks about "users" rather than "subjects" or "principals."

security token service (STS) = issuer
Technically, a security token service is the interface within an issuer that accepts requests and creates and issues security tokens containing claims.

identity provider (IdP) = issuer
An identity provider is an issuer or a "token issuer," if you prefer. Identity providers validate various user credentials, such as user names and passwords, and certificates, and they issue tokens. For brevity, this book uses the term "issuer."

resource security token service (R-STS) = issuer
A resource security token service accepts one token and issues another. Rather than having information about identity, it has information about the resource. For example, an R-STS can translate tokens issued by an identity provider into application-specific claims.
For this book, there's no point in separating the functions of an identity provider, a security token service, and a resource security token service. In fact, much of the existing literature lazily mixes these up, anyway, which just adds to the confusion. This book uses the more practical term, "issuer," to encompass all these concepts.

active client = smart or rich client
passive client = browser
Much of the literature refers to "active" versus "passive" clients. An active client can use a sophisticated library such as Windows Communication Foundation (WCF) to implement the protocols that request and pass around security tokens (WS-Trust is the protocol used in active scenarios). In order to support many different browsers, the passive scenarios use a much simpler protocol to request and pass around tokens that rely on simple HTTP primitives such as HTTP GET (with redirects) and POST. (This simpler protocol is defined in the WS-Federation specification, section 13.)
In this book, an active client is a rich client or a smart client. A passive client is a Web browser.

How This Book Is Structured

You can think of the structure of this book as a subway that has main stops and branches. After the preface, there are two chapters that contain general information. These are followed by scenarios that show how to apply this knowledge with increasingly more sophisticated requirements.
Here is the map of our subway.
Figure 1

"An Introduction to Claims" explains what a claim is and gives general rules on what makes a good claim and how to incorporate them in your application. It's probably a good idea that you read this chapter before you go on to the scenarios.
"Claims-Based Architectures" shows you how to use claims with browser-based applications and smart client–based applications. In particular, the chapter focuses on how to implement single sign-on for your users, whether they are on an intranet or an extranet. This chapter is optional. You don't need to read it before you go on to the scenarios.
"Claims-Based Single Sign-On for the Web" shows you how to implement single-sign on within a corporate intranet. Although this may be something that you can also implement with Windows integrated authentication, it is the first stop on the way to implementing more complex scenarios. It includes a section for Windows Azure™ that shows you how to move the claims-based application to the cloud.
"Federated Identity for Web Applications" shows you how you can give your business partners access to your applications while maintaining the integrity of your corporate directory and theirs. In other words, your partners' employees can use their corporate credentials to gain access to your applications.
"Federated Identity for Web Services" shows you how to use the claims-based approach with Web services, where a partner uses a smart client rather than a browser.
"Federated Identity with Multiple Partners" is a variation of the previous scenario that shows you how to federate with partners who have no issuer of their own as well as those who do. It demonstrates how to use the ASP.NET MVC framework to create a claims-aware application.

What You Need to Use the Code

You can either run the scenarios on your own system or you can create a realistic lab environment. Running the scenarios on your own system is very simple and has only a few requirements. These are the system requirements for running the scenarios on your system:
  • Microsoft Windows Vista SP1, Windows 7, or Microsoft Windows Server 2008 (32-bit or 64-bit)
  • Microsoft Internet Information Services (IIS) 7.0
  • Microsoft .NET Framework 3.5 SP1
  • Microsoft Visual Studio® 2008 SP1
  • Windows Azure Tools for Microsoft Visual Studio
  • Windows Identity Foundation
Running the scenarios in a realistic lab environment, with an instance of Active Directory Federation Services (ADFS) and Active Directory, requires an application server, ADFS, Active Directory, and a client system. Here are their system requirements.

Application Server

The application server requires the following:
  • Windows Server 2008
  • Microsoft IIS 7.0
  • Microsoft Visual Studio 2008 SP1
  • .NET Framework 3.5 SP1
  • Windows Identity Foundation


The ADFS server requires the following:
  • Windows Server 2008
  • Internet Information Services (IIS) 7.0
  • .NET Framework 3.5 SP1
  • SQL Server® 2005/2008 Express Edition

Active Directory

The Active Directory system requires a Windows server 2008 with Active Directory installed.

Client Computer

The client computer requires Windows Vista or Windows 7 for active scenarios. Passive scenarios may use any Web browser as the client that supports redirects

Who's Who

As we've said, this book uses a set of scenarios that traces the evolution of several corporate applications. A panel of experts comments on the development efforts. The panel includes a security specialist, a software architect, a software developer, and an IT professional. The scenarios can be considered from each of these points of view. Here are our experts.
Bharath is a security specialist. He checks that solutions for authentication and authorization reliably safeguard a company's data. He is a cautious person, for good reasons.
"Providing authentication for a single application is easy. Securing all applications across our organization is a different thing."

Jana is a software architect. She plans the overall structure of an application. Her perspective is both practical and strategic. In other words, she considers not only what technical approaches are needed today, but also what direction a company needs to consider for the future.
"It's not easy, balancing the needs of users, the IT organization, the developers, and the technical platforms we rely on."

Markus is a senior software developer. He is analytical, detail-oriented, and methodical. He's focused on the task at hand, which is building a great claims-based application. He knows that he's the person who's ultimately responsible for the code.
"I don't care what you use for authentication, I'll make it work."

Poe is an IT professional who's an expert in deploying and running in a corporate data center. He's also an Active Directory guru. Poe has a keen interest in practical solutions; after all, he's the one who gets paged at 3:00 AM when there's a problem.
"Each application handles authentication differently. Can I get a bit of consistency please?!?"
If you have a particular area of interest, look for notes provided by the specialists whose interests align with yours.

Last edited Jul 7, 2010 at 1:03 AM by eugeniop, version 2


No comments yet.