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 granting permissions to claims in SharePoint 2010 isn’t as complex as it may seem on the first glance. The most important part is correctly retrieving the claim to which you want to grant permissions. The rest is very similar to granting permissions to User or Groups in SharePoint 2007.
For the purpose of this demo I have used the sample Claim Provider included in the SharePoint 2010 SDK. You can download the sample code from http://msdn.microsoft.com/en-us/library/ff604688.aspx.
The following code snippet grants the Read permission to the Executive claim from the CRMClaimProvider:
using (SPSite site = new SPSite("http://sharepoint"))
{
using (SPWeb web = site.OpenWeb())
{
SPClaimProviderManager claimMgr = SPClaimProviderManager.Local;
if (claimMgr != null)
{
SPClaim claim = new SPClaim(ContosoClaimProviders.CRMClaimType.Role,
"Executive",
Microsoft.IdentityModel.Claims.ClaimValueTypes.String,
SPOriginalIssuers.Format(SPOriginalIssuerType.ClaimProvider, ContosoClaimProviders.CRMClaimProvider.InternalName));
string userName = claimMgr.EncodeClaim(claim);
SPUserInfo info = new SPUserInfo
{
LoginName = userName,
Name = "Executive"
};
SPRoleAssignment roleAssignment = new SPRoleAssignment(info.LoginName, info.Email, info.Name, info.Notes);
roleAssignment.RoleDefinitionBindings.Add(web.RoleDefinitions["Read"]);
web.RoleAssignments.Add(roleAssignment);
web.Update();
}
}
}
The first thing it does is to retrieve a reference to the object on which we will be setting permissions. In the above code snippet we will be setting permissions on the Root Web of the Team Site located at http://sharepoint* *(lines 1-3).
Important: In order for the above code snippet to run correctly, the Web Application that you are using it against must be using the Claims Based Authentication instead of the Classic Mode Authentication which is the default setting in SharePoint 2010.
Next we get a reference to the SPClaimProviderManager (line 5) which will help us to convert the claim into a token that can be used for setting the permissions.
The next step is the most important step of the whole process. In this step we create a claim for which we will be granting permissions (lines 8-11). The first parameter is the type of the claim for which we want to grant the permission. In our example we will be setting the permission to the Executive role, so we pass CRMClaimType.Role as the claim type (line 8). The next parameter is the value of the claim, which is Executive in our scenario (line 9). Next we have to pass the type of the claim value which is string (line 10). The type of the claim value is specified by the claim provider. The last parameter that we need to pass is the issuer of the claim. In order for this to work the issuer has to be set to the CRM Claim Provider. You can get the right name by using the SPOriginalIssuers.Format method and passing ClaimProvider as the issuer type and the name of the claim provider as the issuer’s identifier (line 11).
Once the claim is constructed it can be encoded to a token that can be used for granting permissions in SharePoint. To convert the claim into the token we will use the EncodeClaim method of the SPClaimProviderManager (line 12).
At this point we have everything in place to grant permissions to the Executive Role Claim. From the security point of view a claim is being resolved as a user. So in order to grant permission to a claim you have to create an instance of the SPUserInfo class (lines 13-17). While constructing the SPUserInfo object you have to set the token as the user’s login name (line 15), and the value of the claim as the Name (line 16). With that in place we can go further and grant the permissions to the site.
As mentioned before nothing has really changed around programmatically granting permissions to users in SharePoint 2010. First of all you need to create a Role Assignment for the specific Principal (which can be a User or a Group) and then you have to grant it some permissions by adding Role Definitions to the Role Assignment. Once it’s done, the only thing left is to add the Role Assignment to the RoleAssignments collection of the object that you want to secure and apply the changes by updating it.
If you’ve done everything correctly you should see that the Read permissions have been granted to the Executive claim after you run the code.
Summary
SharePoint 2010 ships with Claims Based Identity which is a great way of securing resources as it decouples the authorization from the authentication method. Programmatically granting claims based permissions resembles a lot granting permissions to User and Groups in SharePoint 2007. The most important difference is retrieving the correct claim for which the permissions should be granted.
Technorati Tags: SharePoint 2010