One of the things which pops up quite fast when working with SharePoint and claims based authentication is the weird identifiers you find throughout SharePoint. In one of my troubleshooting sessions I stumbled upon this post which provides a nice picture of the meaning of several parts of an encoded claim.

The post : How Claims encoding works in SharePoint 2010

The picture: Link to original picture (larger)

One thing I came across as well is that when you encode a principal in PowerShell, the shell isn’t capable of showing all encoded strings. Especially the 6th character is often displayed as a ? while in reality it’s some exotic character. The following lines of PowerShell code should print the SharePoint representation of the given claim (with it’s type and value)

• $mgr = Get-SPClaimProviderManager
• $tp = Get-SPTrustedIdentityTokenIssuer -Identity "Cust ADFS Provider"
• $cp = Get-SPClaimProvider -Identity "ADFSClaimsProvider"
• $claim = New-SPClaimsPrincipal -ClaimValue "readPermission" -ClaimType http://schemas.customer.com/claims/technicalrole -TrustedIdentityTokenIssuer $tp
• $mgr.EncodeClaim($claim)

However if you want to see how the encoded claim really looks, I advise you to capture the output of $mgr.EncodeClaim($claim) and pipe it to Out-File claim.txt E.g.

• $mgr.EncodeClaim($claim) | out-file claim.txt

To conclude this post, I would advise to never hardcode any encoded claims in your scripts or code. After all the 4th character is generated on a per farm base and could very well be different in another SharePoint environment. As long as you keep encoding the claim based upon the actual input (claim value, type & provide), you should be safe though.