Professional SharePoint 2010 Cloud-Based Solutions by Wrox!

Steve Fox was the driver behind this and it was a great opportunity to team up with him and my other colleagues Paul Stubbs and Girish Raja to write this book.

Professional SharePoint 2010 Cloud-Based Solutions is primarily for IT Pros, SharePoint Developers and enthusiasts who want to better understand how to leverage the cloud in/from their SharePoint solutions/installations. Each chapter is designed to expose some form of integration with SharePoint and the cloud. This includes Web 2.0 technologies, Windows Azure and other cloud-based services. Since SharePoint 2010 and Office 2010 are hand-in-glove, the book also shows how to land cloud-based data into Office client applications and Excel Services under SharePoint.

What I believe is most helpful in the book, is that each chapter provides a conceptual overview of the technologies used in building cloud-based solutions. It then provides a high-level architecture for a solution and then lays out the practical step-by-step instructions to walk through a sample concept-to-practical solution. Our intent for the book is not to just talk about what you might do, but to describe the concepts and then show you how to do a small project and get you rolling.

One of the concepts you may need to have an awareness of in building your cloud-based solutions for SharePoint is claims-based identity and how to build a single-signon solution between a cloud-based web application and surface it in SharePoint. Following is an excerpt from chapter 11 to give you a flavor of how to understand the concepts used in claims-based identity. The full chapter then goes on to explain how to wire all this up, but here’s an overview of the claims-based identity concepts…

<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>

All in all, the claims-based identity components called out within specific technical implementations can often be somewhat confusing; however, the preceding analogy will help you roll back the technical details into a practical scenario you are familiar with as you work with determining all the components needed when implementing your claims-based identity solutions.

With that, click here and browse around inside the book and check out the table of contents.

Thanks again to Steve, Paul and Girish for the opportunity to work with you on this.

Enjoy!

Comments

• Anonymous
  December 13, 2011
  That is by far the best "real world" analogy that I've read for Claims Auth