Now I understand claims based identity

"In companies with Federated Identity set up, users can sign into Office 365 services using their Active Directory credentials. The corporate Active Directory authenticates the users, and stores and controls the password policy. With federated Identity, credentials are authenticated by on premises Active Directory Federation Services server and a logon token is obtained by the user so that the Office 365 sign-in service can verify them"

This all sounds very easy and digestible? No? Does the below diagram help? If no/maybe read on...

I'd like to think that I understand the concept of claims based identity, but because its such an important part of Office 365, I've always wanted to be able to explain the concept to others in an easy and digestible way. Luckily some of my colleagues wrote a book (Professional SharePoint 2010 Cloud-Based Solutions) in which they wrote the best explanation I've ever seen on the topic. In fact its so good I encourage you to read the below excerpt from the book (source: Donovan Follette - one of the authors blog post)

<excerptFromProfessionalSharePoint2010Cloud-BasedSolutions>

OVERVIEW OF CLAIMS-BASED IDENTITY

Claims-based identity is not a new concept, either in the practical world or within technology; it’s just that we don’t readily identify it as such in our day-to-day activities as easily as we can recognize it when it’s implemented with technology. Therefore, before we delve into claims-based identity within its technical implementation, this section looks at a practical scenario you have likely encountered, which you can use to help connect the dots to understand the concepts of claims-based identity when applied in technology.

Morgan arrives at the pharmaceutical conference eager and ready to participate for the next three days. She will have a triple role within the conference. First, since her company is a conference sponsor, she will spend part of her time in the company booth in the exhibit hall talking with conference attendees. Second, she is a conference speaker for one of the sessions. And, finally, she will be attending as many other sessions as possible for personal and professional enrichment.

Her first stop is at the registration booth, where Dean asks her to present a picture ID, which can only be a valid driver’s license or passport. Upon verifying her identity, the registrar provides her with a conference badge that includes her name, company name, bar code identifier, and three different colored ribbons to attach to the badge: a red exhibitor ribbon, a yellow speaker ribbon, and a white attendee ribbon. As you no doubt have surmised, each ribbon has different rights and privileges associated with it within the conference site.

Morgan tucks away her picture ID, securely attaches the ribbons to the badge, hangs it around her neck, and proceeds to the area to pick up the conference materials. At the distribution table, the person sees the white ribbon and provides a conference bag with all the materials for an attendee. Morgan then wants to see the booth area, so she visits the exhibit hall. Although it’s not yet open to attendees, the exhibit hall doorkeeper sees her red exhibitor ribbon and grants her access into the hall. After a brief visit with her colleagues, Morgan heads to the speaker preparation room to add the final touches to her presentation. Here again she is granted access, as she has the required yellow speaker ribbon.

This simple scenario illustrates the components of a claims-based identity system. There are specific identity providers (IPs) that the conference registrar will trust. In this case it is either a state department of licensing agency that has verified an individual’s identity and issued a driver’s license, or a government that has performed the verification and issued a passport. In either case the document they issue is considered an acceptable security token and can be validated by checking its specific security markings that warrant its authenticity.

The security token itself contains one or more claims — that is, statements about the subject, such as name, birth date, height, weight, photograph, and so on. These are called claims because they are supposedly true statements about the subject, but they are trusted only to the extent to which the IP that issued the security token is trusted. In other words, Morgan could have showed the registrar another security token — for example, her corporate picture ID card — that had almost all the same claims as her driver’s license. Even though this company-issued security token is truly authentic, and valid for Morgan in other contexts, it is not recognized by the conference. Although her company, as an IP, issued the security token with claims about her, the registrar could only accept trust statements about her when they were present in security tokens issued by state or government IPs.

A security token service (STS) determines the trust relationships it will have with other STSs in a claims-based identity system. Trust relationships can be established between an IP STS and a federation provider (FP) STS, sometimes called a resource STS (R-STS) . The registrar in this scenario performs the role of the FP STS. The registrar verified that the security token provided for identification was authentic and from a trusted IP STS — and note his next action. In turn, he issued a brand-new security token: the badge, with its claims in the form of text, name, company, etc., and colored ribbons. It is this new security token that is trusted within the conference site (security domain) by all the different parties that will rely upon it. Essentially, the registrar accepted one security token, validated its authenticity, and then issued another security token scoped for another security domain, the conference. For Morgan, the original security token was no longer needed. Once the badge and ribbons were issued by the registrar FP STS, her driver’s license was put away and only her badge was required within the conference site.

Within the conference security domain, the relying party (RP) applications are the doorkeepers at the various session rooms, speaker preparation rooms, and exhibit halls. The RP cares nothing about whether the conference attendee showed a driver’s license or passport to the registrar. The RP needs only to trust the registrar FP STS, and relies upon it to provide the attendee with the conference badge security token, with its appropriate claims. Upon the basis of this trust, the RP can check the colored ribbon claim to grant/deny access to the appropriate venue. The additional claims on the badge are not required for access, but can be captured by handheld scanning devices to track attendance at each session and to collect leads by exhibitors in the exhibit hall.

Does this scenario sound familiar? This is claims-based identity in action, and it happens in many aspects of our daily lives; we just don’t readily recognize it  — subject, trust, IP, STS, FP, security domain, security token, and claims are parts of everyday life.

Claims-based identity, therefore, is based on the ability of a security token service to encapsulate claims about a subject within a security token structure and issue the security token. Trust relationships are established between identity provider STSs, resource STSs, and relying party applications so that authenticity of an issued security token can be verified before being trusted by the relying party.

</excerptFromProfessionalSharePoint2010Cloud-BasedSolutions>

Thank you for reading to the very end of this (text heavy) post. I hope you now understand claims based identity a little better.