This property of a claim in System.IdentityModel can be confusing. It's documented as only being able to have the values defined in the Rights class, which are PossessProperty and Identity (I'm not going to write out the full URIs - check the Rights class for those). As of this writing the documentation for Claim.Right incorrectly states that Read and Write are also valid values, which makes me curious if there were originally more values in the Rights class than there are now.
Back in the beta when I was getting my head around claims-based identity, I didn't pay too much attention to the Right on a claim, because frankly I didn't get it. But as it's currently defined, it does seem pretty straightforward.
In a WCF service, if you look at a claim dump from a client using Windows creds, you'll see a bunch of SIDs. They are all listed as PossessProperty claims, and the User SID is also copied in the ClaimSet and labeled as an Identity claim. Similarly, if you dump the claims from a cert-based client you'll see the name, public key, and thumbprint from the cert as PossessProperty claims, and then the thumbprint claim is duplicated as an Identity claim.
Back in the beta, I remember asking Gudge in a phone conversation about the difference between PossessProperty and Identity claims, and he seemed to have the same impression as I did at the time: PossessProperty represents something the subject has, and Identity represents something the subject is. Of course that doesn't really help to explain why the thumbprint on a cert is used as an Identity claim! When you've got a bunch of claims describing a client's identity, it seems as though all of them describe something the subject is. So is-a versus has-a is clearly not precise enough.
From a purely practical standpoint, if you compare the claim dumps I described above, it's pretty clear to me how WCF is using Claim.Right today. It's used to indicate what WCF considers the primary key of the user's identity. If you think of a row in a database, some of those columns are typically part of the primary key for the table. Correspondingly, I could imagine seeing one or more claims where Claim.Right was set to Identity, and using the values of those claims to index into a record representing the subject of the ClaimSet.
In case anyone else was confused about what ClaimType.Right really means, I hope that the thread that ensues from this post will help clear up that confusion. I'd also love to hear Microsoft's take on what ClaimType.Right represents, and where we can expect it to be extended in the future. What other Rights is MS considering adding in the future, or is ClaimType.Right relegated to being a boolean field as it appears now?
Posted
May 11 2007, 02:28 PM
by
keith-brown