Sometimes claims are referred to as “metadata about a user”. To over-simplify the topic, we sometimes hear them spoken about as Active Directory attributes or LDAP attributes. People often talk about the concept of claims in a very simple manner, saying that claims represent user attributes or attributes about a user. To understand the concept, you have to view claims as an assertion that I make about myself. In other words, a claim is an attribute that I claim to have or be. For example, I can tell you that I am Canadian. I can tell you I’m a Canadian of Italian heritage. You may or may not believe me. This is something that I’m claiming about my identity. If you were to look at my passport, perhaps you’d be more inclined to believe this claim, because my passport is an official document that many agencies trust. If you were to ask someone that you trust about me, and that person happens to know me well, then you would likely be inclined to trust what they say about me.
In the digital world, a claim must be trusted by the dependant application. For example, SharePoint must trust a claims provider like ADFS2. An application trusts a claim about a user’s identity if it is issued to the calling application by a trusted identity provider. So when creating or deploying a claims aware application, it is important to establish a trust relationship between that claims-aware application (the relying party) and the claims issuer (sometimes called a claims identity provider).
Claims offer us much more than just retrieving attributes from a directory. As an example, consider the scenario where a corporation’s external partner is not permitted to connect their system to the organization’s internal directory to retrieve attributes. Even if they are permitted to connect, the partner has no way of trusting those attributes because they have no way of validating them. As well, for the organization, there really is no effective way of limiting what attributes each calling application is permitted to access.
The real power of claims becomes evident when you consider the following points:
- Claims are issued to applications by trusted identity providers
- These trusted identity providers can be on-premise, in the cloud, inside or outside the enterprise
- Trusted identity providers can be configured to only return certain claims to specific trusted calling applications
- Claims tokens are digitally signed and communicated back to the calling application using standards based protocols (like SAML)
- Claims are packaged up into tokens using standards based formats (like WS-Federation or SAML)
Claims allow us to take identities across network boundaries in a secure and trusted way, enabling us to solve some new and exciting challenges for our customers. These challenges include federation, complex authentication requirements, as well as authorization based on not only who I am, but what my clearance level is, if I’m connecting over a secure connection or an internet cafe, the time of day, if I need two factor authentication for specific systems or sites, and so on.
SharePoint Blog 