Preventing authenticated visitors from browsing system pages

When building an Internet-facing website on the SharePoint 2010 platform, the last thing you want is to have your visitors browse your system pages. To prevent this from happening, SharePoint 2010 has the ViewFormPagesLockdown Feature. But what if your visitors are authenticated?

Programmatically granting permissions to claims

Programmatically granting permissions in SharePoint 2007 wasn’t that very complicated. You could grant permissions either to a User or a Group and in order to do that all you needed was a reference to that User/Group. As you might have heard SharePoint 2010 supports claims based identity what allows you to grant permissions using the identity of the user rather than a specific way of authentication. If you’ve looked through the public SharePoint 2010 API you might have noticed that there is no specific method that allows you to programmatically grant permissions to a claim. So how do you do that?

Programmatically determining which Claims Authentication Type has been used to login with Claims Based Authentication

Claims Based Authentication introduced with SharePoint 2010 allows you to login to a SharePoint site using multiple Authentication Providers. In some scenario you might need to determine which Claims Authentication Type has been used to login in order to conditionally show some content. Find out how this can be done using the new Claims API provided with SharePoint 2010.

Programmatically converting login name to claim and vice versa

SharePoint 2010 introduced Claims Based Authentication. One of the consequences of this is the fact that in order to use Forms Based Authentication (FBA) you need to configure your Web Application to use Claims instead of Classic Authentication. One of the many changes that you notice while working with claims are different login names: while in SharePoint 2007 you used something like myprovider:myuser, SharePoint 2010 makes the claims-soup of it: i:0\#.f|myprovider|myuser. And while this is something you can take into account for newly created solutions, it can get confusing when upgrading SharePoint 2007 solutions to SharePoint 2010, especially if all you need is the user name. So is String.Replace the only way to get it out or is there a better way?