The Claims-Based Identity Model
[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.]
When you build claims-aware applications, the user presents an identity to your application as a set of claims. One claim could be the user’s name, another might be an e-mail address. The idea here is that an external identity system is configured to give your application everything it needs to know about the user with each request she makes, along with cryptographic assurance that the identity data you receive comes from a trusted source.
Under this model, single sign-on is much easier to achieve, and your application is no longer responsible for the following:
Authenticating users.
Storing user accounts and passwords.
Calling to enterprise directories to look up user identity details.
Integrating with identity systems from other platforms or companies.
Under this model, your application makes identity-related decisions based on claims supplied by the user. This could be anything from simple application personalization with the user’s first name, to authorizing the user to access higher valued features and resources in your application.
It’s not Just About Federation
The original intention behind the claims-based identity model was to enable federation between organizations, but over time it’s become apparent that claims aren’t just for federation. But some of these terms remain. For example, when you use WIF in your ASP.NET application, you’ll need to use a WIF component called the WSFederationAuthenticationModule in order to perform claims processing. Don’t let the word “federated” mislead you. There are clear benefits to building applications that outsource authentication and authorization. Any company that has, or plans to have in the future, more than one Web application or Web service, can benefit by starting with a claims-based model for identity.
Introduction to Claims-Based Identity
This section of the topic introduces terminology and concepts to help you understand this new architecture for identity.
Identity
The word “identity” is an often ambiguous term. This topic has used it to describe authentication and authorization, for example. But for the purposes of describing the programming model in WIF, we will use the term “identity” to describe a set of attributes that describe a user or some other entity in a system that you want to secure.
Claim
Think of a claim as a piece of identity information such as name, e-mail address, age, membership in the Sales role. The more claims your application receives, the more you’ll know about your user. You may be wondering why these are called “claims,” rather than “attributes,” as is commonly used in describing enterprise directories. The reason has to do with the delivery method. In this model, your application doesn’t look up user attributes in a directory. Instead, the user delivers claims to your application, and your application examines them. Each claim is made by an issuer, and you trust the claim only as much as you trust the issuer. For example, you trust a claim made by your company’s domain controller more than you trust a claim made by the user herself. WIF represents claims with a Claim type, which has an Issuer property that allows you to find out who issued the claim.
Security Token
The user delivers a set of claims to your application along with a request. In a Web service, these claims are carried in the security header of the SOAP envelope. In a browser-based Web application, the claims arrive through an HTTP POST from the user’s browser, and may later be cached in a cookie if a session is desired. Regardless of how these claims arrive, they must be serialized, which is where security tokens come in. A security token is a serialized set of claims that is digitally signed by the issuing authority. The signature is important: it gives you assurance that the user didn’t just make up a bunch of claims and send them to you. In low security situations where cryptography isn’t necessary or desired, you can use unsigned tokens, but that scenario is not described in this topic.
One of the core features in WIF is the ability to create and read security tokens. WIF and the .NET Framework handle all of the cryptographic work, and present your application with a set of claims that you can read.
Issuing Authority
There are lots of different types of issuing authorities, from domain controllers that issue Kerberos tickets, to certification authorities that issue X.509 certificates, but the specific type of authority discussed in this topic issues security tokens that contain claims. This issuing authority is a Web application or Web service that knows how to issue security tokens. It must have enough knowledge to be able to issue the proper claims given the target relying party and the user making the request, and might be responsible for interacting with user stores to look up claims and authenticate the users themselves.
Whatever issuing authority you choose, it plays a central role in your identity solution. When you factor authentication out of your application by relying on claims, you’re passing responsibility to that authority and asking it to authenticate users on your behalf.
Standards
In order to make all of this interoperable, several WS-* standards are used in the previous scenario. Policy is retrieved using WS-MetadataExchange, and the policy itself is structured according to the WS-Policy specification. The STS exposes endpoints that implement the WS-Trust specification, which describes how to request and receive security tokens. Most STSs today issue tokens formatted with Security Assertion Markup Langauge (SAML). SAML is an industry-recognized XML vocabulary that can be used to represent claims in an interoperable way. Or, in a multi-platform situation, this allows you to communicate with an STS on an entirely different platform and achieve single sign-on across all of your applications, regardless of platform.
Browser-Based Applications
Smart clients aren’t the only ones who can use the claims-based identity model. Browser-based applications (also referred to as passive clients) can use it as well. The following scenario describes how this works.
First, the user points a browser at a claims-aware Web application (the relying party application). The Web application redirects the browser to the STS so the user can be authenticated. The STS is hosted in a simple web application that reads the incoming request, authenticates the user using standard HTTP mechanisms, and then creates a SAML token and replies with a piece of JavaScript code that causes the browser to initiate an HTTP POST that sends the SAML token back to the RP. The body of this POST contains the claims that the RP requested. At this point, it is common for the RP to package the claims into a cookie so that the user doesn’t have to be redirected for each request.
Information Cards and the Identity Selector
WIF offers APIs for Information Card serialization that can be used for building managed card issuance and enabling Information Card sign-in in applications. For more information about, see Windows CardSpace
An identity selector provides the following features:
Helps users manage multiple identities for the Web.
Helps users select an appropriate identity for a given relying party.
Helps protect user privacy.