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.
Common Scenarios
"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.
