Programming SharePoint permissions, simplified

The other day I ran into an issue that I'd had a frustrating time wrapping my head around in the past: assigning SharePoint permissions programmatically.

I have found that there is very little on the internet that gives a clear explanation of how permissions work or how to do it on a general basis. Mainly I found examples without clear explanations for what was happening or what needed to be done.

So I'll try my best in this post so summarize it for anyone else that may be running into similar issues.

SharePoint permissions function with 4 general parts: (bear with me, I'll break this down)

• The Role
• The Principal
• The Securable object
  
• The Assignment (the key to it all!)
  

The Role is the set of permissions that will be assigned. These can be set in a number of ways from an existing role or by defining your own set of base permissions that the role will posses. The possible permissions are contained in the SPBasePermissions enumeration.

Defining your own role is done like this:

//Create Role
SPRoleDefinition newRole = new SPRoleDefinition();

//Name the role, then assign permissions to it
newRole.Name = "New Role";
NewRole.BasePermissions = SPBasePermissions.EditListItems | SPBasePermissions.AddListItems | ...;

The Principal is the object that you will be binding the permissions to. This is usually either an SPUser or SPGroup. What this means is that you have a group (or user) that you want to assign permissions to, so you create an SPRoleDefinition object that defines what permissions the group (or user) needs to have then you bind these permissions to the group.

The Securable object is what you want to lock down. This can be a list, web, site, library, library item, even a group.

The Assignment object is what ties everything together. It binds the Principal to the SPRoleDefinition and it assigns the Group to the securable object.

Demonstrated: (First, creating a new list to be secured; Second, creating a group to be assigned the permissions and securable object; Finally, tying the RoleDefinition created earlier to the group, then assigning the group to the new list...pardon the lack of indentation)

//Don't want to get caught with your SPWeb open...
using (SPSite mySite = new SPSite(SPContext.Current.Site.Url)
{
using (SPWeb myWeb = mySite.OpenWeb())
{

//Creates list
Guid ListId = myWeb.Lists.Add("New List", "Demo List", SPListTemplateType.GenericList);

//Create Group
myWeb.SiteGroups.Add("NewGroup", myWeb.Users[myWeb.CurrentUser.Name], myWeb.CurrentUser, "Demo Group");

SPGroup myGroup = myWeb.SiteGroups["NewGroup"];

//Creates Role Assignment and ties it to the new Group
SPRoleAssignment NewRA = new SPRoleAssignment((SPPrincipal)myGroup);

//Binds the role to the group
NewRA.RoleDefinitionBindings.Add(newRole);

SPList myList = myWeb.Lists[ListId];

//You have to break inheritance to assign different principals to inheriting securable objects
if (myList.HasUniqueRoleAssignments)
{
//This can cause problems on postbacks, so as always in sharepoint, use try catch blocks
myList.BreakRoleInheritance(false);
}

//Add RoleAssignment to the new List
myList.RoleAssignments.Add(NewRA);

//You can also set item level read and write security (for lists)!
// If you set this, make sure someone has the SPBasePermission: ManageList or no one will be able to see all the items.
//for read: 1 is no security, 2 is read only your own.
myList.ReadSecurity = 2;
//For write: 1 is no security, 2 is edit your own, 4 is edit no items.
myList.WriteSecurity = 2;

}
}//All done!

Hopefully this will help someone else and at least for me I can look back to remember how to do it when I have to do it again.