Preface

As an application designer or developer, imagine a world in which 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 email address, a manager's email 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), Microsoft Active Directory® directory service, and Microsoft Visual C#® development system.

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) 2.0. 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, when it is discussing the functionality of the application, and relying party or RP, when it is talking about the role of the application in relation to identity providers and federation providers. It does not use 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 such 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, passwords, and certificates; and they issue tokens.

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.

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 lines and branches. Following 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

Map of the book

An Introduction to Claims explains what a claim is and provides general rules on what makes good claims and how to incorporate them into your application. It's probably a good idea that you read this chapter before you move on to the scenarios.

Claims-Based Architectures shows you how to use claims with browser-based applications and smart client 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 proceed to the scenarios.

Claims-Based Single Sign-On for the Web and Microsoft Azure™ is the starting point of the path that explores the implementation of single sign-on and federated identity. This chapter shows you how to implement single sign-on and single sign-out within a corporate intranet. Although this may be something that you can also implement with Integrated Windows Authentication, it is the first stop on the way to implementing more complex scenarios. It includes a section for Azure® technology platform that shows you how to move the claims-based application to the cloud.

Federated Identity for Web Applications shows 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 own corporate credentials to gain access to your applications.

Federated Identity with Azure Access Control Service is the start of a parallel path that explores Azure AppFabric Access Control Service (ACS) in the context of single sign-on and federated identity. This chapter extends the scenarios described in the previous chapter to enable users to authenticate using social identity providers such as Google and Windows Live® network of Internet services.

Federated Identity with Multiple Partners is a variation of the federated identity 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.

Federated Identity with Multiple Partners and Azure Access Control Service extends the scenarios described in the previous chapter to include ACS to give users additional choices for authentication that include social identity providers such as Google and Windows Live.

Claims Enabling Web Services is the first of a set of chapters that explore authentication for active clients rather than web browsers. This chapter shows you how to use the claims-based approach with web services, whereby a partner uses a smart client that communicates with identity providers and token issuers using SOAP-based services.

Securing REST Services shows how to use the claims-based approach with web services, whereby a partner uses a smart client that communicates with identity providers and token issuers using REST-based services.

Accessing REST Services from a Windows Phone Device shows how you can use claims-based techniques with Windows Phone™ wireless devices. It discusses the additional considerations that you must take into account when using claims-based authentication with mobile devices.

Claims-Based Single Sign-On for Microsoft SharePoint 2010 begins a path that explores how you can use claims-based identity techniques with Microsoft SharePoint 2010. This chapter shows how SharePoint web applications can use claims-based authentication with an external token issuer such as ADFS to enable access from both internal locations and externally over the web.

Federated Identity for SharePoint Applications extends the previous chapter to show how you can use federated identity techniques to enable users to authenticate using more than one identity provider and token issuer.

About the Technologies

In this guide, you will find discussion on several technologies with which you may not be immediately familiar. The following is a brief description of each one, together with links to where you can find more information.

Windows Identity Framework (WIF). WIF contains a set of components that enable developers using the Microsoft .NET Framework to externalize identity logic from their application, improving developer productivity, enhancing application security, and enabling interoperability. Developers can apply the same tools and programming model to build on-premises software as well as cloud services without requiring custom implementations. WIF uses a single simplified identity model based on claims, together with interoperability based on industry-standard protocols. For more information see "Windows Identity Foundation Simplifies User Access for Developers," at https://msdn.microsoft.com/en-us/security/aa570351.aspx.

Active Directory Federation Service (ADFS). ADFS is a server role in Windows Server® that provides simplified access and single sign-on for on-premises and cloud-based applications in the enterprise, across organizations, and on the web. It acts as an identity provider and token issuer to enable user access with native single sign-on across organizational boundaries and in the cloud, and to easily connect applications by utilizing industry-standard protocols. For more information, see "Active Directory Federation Services 2.0," at https://www.microsoft.com/windowsserver2008/en/us/ad-fs-2-overview.aspx [Note: this link has been deprecated. Information on ADFS v2 can be found on TechNet at https://technet.microsoft.com/en-us/library/adfs2(v=ws.10).aspx].

Azure. Azure is a cloud services platform that serves as the development, service hosting and service management environment. It is a flexible platform that supports multiple languages and provides developers with on-demand compute and storage services to host, scale, and manage web applications over the Internet through Microsoft datacenters. For more information, see "Microsoft Azure," at https://www.microsoft.com/windowsazure/windowsazure/default.aspx.

Azure AppFabric Access Control Service (ACS). ACS is an easy way to provide identity and access control to web applications and services while integrating with standards-based identity providers. These identity providers can include enterprise directories such as Active Directory, and web identities such as Windows Live ID, Google, Yahoo! and Facebook. ACS enables authorization decisions to be moved out of the application and into a set of declarative rules that can transform incoming security claims into claims that applications understand, and can also be used to manage users’ permissions. For more information, see "Microsoft Azure Access Control," at https://www.microsoft.com/windowsazure/appfabric/overview/default.aspx.

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, which are listed below.

• Microsoft Windows Vista® SP1, Windows 7, Windows Server 2008 (32-bit or 64-bit), or Windows Server 2008 R2 (32-bit or 64-bit)
• Microsoft Internet Information Services (IIS) 7.0 or 7.5
• Microsoft .NET Framework 4.0
• Microsoft Visual Studio® 2010 (excluding Express editions)
• Microsoft 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 or Windows Server 2008 R2
• Microsoft Internet Information Services (IIS) 7.0 or 7.5
• Microsoft Visual Studio 2010 (excluding Express editions)
• .NET Framework 4.0
• Windows Identity Foundation

ADFS

The ADFS server requires the following:

• Windows Server 2008 or Windows Server 2008 R2
• Microsoft Internet Information Services (IIS) 7.0 or 7.5
• .NET Framework 4.0
• Microsoft SQL Server® 2005 or 2008 Express Edition

Active Directory

The Active Directory system requires Windows Server 2008 or Windows Server 2008 R2 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 that supports HTTP redirection as the client.

Who's Who

As we've said, this book uses a number of scenarios that trace 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.

If you have a particular area of interest, look for notes provided by the specialists whose interests align with yours.

Revised 27 July 2015: Removed outdated link to ADFS v2.0 information.

Next | Home