One of the interesting problems I was working on last week had to do with some strange permissions errors on a claims auth site. Part of the difficulty in troubleshooting the situation is that we were not / are not enumerating the claims that SharePoint thinks we have and dumping them out anywhere. So when I went to a site and either got an access denied, or didn’t have access to all of the content that I thought I should, I didn’t have a good way to figure out why that was. To help debug those types of scenarios I wrote a fairly simple piece of code last to tell me what claims SharePoint has for me, the current user request. I implemented this in two ways. One part is implemented as an HttpModule. It enumerates the claims and then outputs them to the ULS log. You can easily find these entries by filtering the ULS log on the category “SharePoint Claims Enumeration”. The HttpModule is useful for cases where you are not even able to log into the site. The second part of the assembly is implemented as a web part. It just emits the claims you have and the value for each claim. That is useful in the scenario where you can log on but you are trying to troubleshoot why you don’t have access to all of the content you think you should have. I’m attaching a zip file to this posting. It contains the source code and debug version of this assembly; read the instructions.txt file to see how to add into your site.
One other thing that is IMPORTANT that I learned about claims in SharePoint last week. After you authenticate to your STS, your token comes back to SharePoint. SharePoint has this list of all the claims it is expecting to see – it looks for all of those and builds them into an SPClaim. If your STS sends back other claims besides what SharePoint is expecting, SharePoint will IGNORE all of those additional claims and it WILL NOT be added to the SPClaim. This is another thing that may be useful to remember when trying to troubleshoot claims auth issues.
You can download the attachment here: