In SharePoint 2010, security has been implemented based upon user, groups and their ACL. Both Active Directly Users and Active Directory groups are represented by SPUser objects in the SharePoint object model. The reason for this goes back to the asp.net provider model, since the actual implementation of the authentication and authorization mechanism is abstracted, it’s necessary to have an abstract notion of the user that should be granted permissions on a resource. This is done via the abstract SPPrincipal object and it’s descendants, SPUser and SPGroup in SharePoint. The benefit of this abstraction is that SPUser object can represent Active Directory users or groups or custom users authenticated via forms authentication and by extension the SPGroup object which represents a collection of SPUser object can contain a heterogeneous collection of SPUser objects, allowing permissions to be defined regardless of the authentication mechanism.

Now that we’ve covered how users and user groups are represented in the SharePoint security object model, the next thing to consider is access control. Many of the objects in a SharePoint application can have access control lists (ACLs) attached to them. An ACL is a binary data structure that contains details of the SPPrincipal objects that have permissions defined for the object together with information on the permissions. Each principal/permission mapping is represented by an SPRoleAssignment object. You’ll notice from the name, that a SPRoleAssignment doesn’t actually map permissions to principals directly, in fact there’s a further level of grouping that’s represented by the SPRoleDefinition object. An SPRoleDefintion object is a collection of bits that represent the status of a number of pre-defined permission flags. The individual flags are listed in the SPBasePermissions enumeration. While actual permissions are hardcoded into the SharePoint platform, SPRoleDefinitions are user-defined and the system-defined permissions are fine-grained enough to allow users to create roles that encompass practically any security requirement.

SPRoleDefintions are stored at the SPWeb level and are accessible through the Roles property of the SPWeb object.

The three main objects that can be secured in SharePoint implement the ISecurableObject interface. These objects are:

· SPWeb, which represents an entire web site. Permissions defined at this level are inherited by all lists contained within the web unless inheritance has been explicitly turned off. Sub-web’s also inherit permissions defined here unless inheritance has been turned off.

· SPList, which represents all lists and document libraries within a web site. Permissions defined at this level automatically apply to all items contained within the list or library unless inheritance has been explicitly turned off.

· SPListItem, which represents the lowest level of access control available in SharePoint. Permissions defined at this level apply to a single document or data item.

You’ll no doubt be aware that these are some of the most fundamental objects used when building applications with SharePoint, so much so that many of the other objects that are commonly used either inherit from these types or have methods that can return an associated instance of these types. For example the SPFolder object has a ParentListId property that can be used to get a reference to the containing list, or the SPFile object has an Item property that returns an SPListItem object that represents the file. Since it is our aim to create a utility that will allow declarative configuration of security in SharePoint, it is vital that we can manage ACL’s on all objects that implement the ISecurableObject interface, particularly those described above.

So to recap, the key objects and interfaces that will be required for our configuration utility are:

· SPPrincipal – an abstract class that provides the base for SPUser and SPGroup. This class allows permissions to be set based on group membership or on a per-user basis (subject to the caveat that an SPUser isn’t necessarily only a single user)

· SPUser – represents a discrete security entity in SharePoint. This can be a user, a local user group or an Active Directory group.

· SPGroup – represents a group of SPUser objects

· SPRoleAssignment – represents an entry in the ACL for a particular role

· SPRoleDefintion – represents the combination of permissions that should be applied for a particular user on a particular resource

· SPBasePermission – an enumeration that lists the system level permissions that can be used when creating SPRoleDefinitions

· ISecurableObject – represents a resource that can be secured via an access control list

SharePoint security UI walkthrough

Let’s have a look at the SharePoint 2010 UI, Go to “Site Settings -> Site Permissions”, you will able to see all the SharePoint Groups, Domain Groups and SharePoint users. This list also provides the permission level of the groups and users which will one or move i.e. approve and Read.

· Grant Permission to provide the access to user and groups. You will two ways to grant the access:-

o Add users to SharePoint Group (recommended) to add your users/ domain groups to SharePoint Groups. It automatically cascade the permission to the users.

o Grant Permission Directly gives you granular level permission which specifies the built-in permissions available in SharePoint Foundation.

List Permissions
	Manage Lists  –  Create and delete lists, add or remove columns in a list, and add or remove public views of a list.
	Override Check Out  –  Discard or check in a document which is checked out to another user.
	Add Items  –  Add items to lists and add documents to document libraries.
	Edit Items  –  Edit items in lists, edit documents in document libraries, and customize Web Part Pages in document libraries.
	Delete Items  –  Delete items from a list and documents from a document library.
	View Items  –  View items in lists and documents in document libraries.
	Approve Items  –  Approve a minor version of a list item or document.
	Open Items  –  View the source of documents with server-side file handlers.
	View Versions  –  View past versions of a list item or document.
	Delete Versions  –  Delete past versions of a list item or document.
	Create Alerts  –  Create alerts.
	View Application Pages  –  View forms, views, and application pages. Enumerate lists.
Site Permissions
	Manage Permissions  –  Create and change permission levels on the Web site and assign permissions to users and groups.
	View Web Analytics Data  –  View reports on Web site usage.
	Create Subsites  –  Create subsites such as team sites, Meeting Workspace sites, and Document Workspace sites.
	Manage Web Site  –  Grants the ability to perform all administration tasks for the Web site as well as manage content.
	Add and Customize Pages  –  Add, change, or delete HTML pages or Web Part Pages, and edit the Web site using a Microsoft SharePoint Foundation-compatible editor.
	Apply Themes and Borders  –  Apply a theme or borders to the entire Web site.
	Apply Style Sheets  –  Apply a style sheet (.CSS file) to the Web site.
	Create Groups  –  Create a group of users that can be used anywhere within the site collection.
	Browse Directories  –  Enumerate files and folders in a Web site using SharePoint Designer and Web DAV interfaces.
	Use Self-Service Site Creation  –  Create a Web site using Self-Service Site Creation.
	View Pages  –  View pages in a Web site.
	Enumerate Permissions  –  Enumerate permissions on the Web site, list, folder, document, or list item.
	Browse User Information  –  View information about users of the Web site.
	Manage Alerts  –  Manage alerts for all users of the Web site.
	Use Remote Interfaces  –  Use SOAP, Web DAV, the Client Object Model or SharePoint Designer interfaces to access the Web site.
	Use Client Integration Features  –  Use features which launch client applications. Without this permission, users will have to work on documents locally and upload their changes.
	Open  –  Allows users to open a Web site, list, or folder in order to access items inside that container.
	Edit Personal User Information  –  Allows a user to change his or her own user information, such as adding a picture.
Personal Permissions
	Manage Personal Views  –  Create, change, and delete personal views of lists.
	Add/Remove Personal Web Parts  –  Add or remove personal Web Parts on a Web Part Page.
	Update Personal Web Parts  –  Update Web Parts to display personalized information.

· Create Group is to create more SharePoint Group.

· Edit User Permissions option is to change the permission of users and group in SharePoint.

· Remove User Permissions to remove all the permission from SPUser (Domain group, SharePoint Group and users) from SharePoint site.

· Check Permissions to check user/group list, site and personal permissions.

· Permission level to role to describe to access of the user all over the site.

· Site Collection Administrators provides you the list of administrator of the site. If you have implemented the Break Role Inheritance or unique permission on SPWeb, SPList and SPListItem, then there will be a notification message i.e. “Site content on this site has unique permissions which are not controlled from this page. And A link to the uniquely secured content”.

The following diagram shows an object hierarchy for a document library, in which all objects but one inherits their scope from their parents. Each numbered gold hexagon represents a permissions scope. All child objects within a container inherit from that parent scope unless they have their own unique permissions scope.

If you have a sub-site and you go to Site Actions -> Site Permissions, you will be able to see the parent users and groups with the notification “This Web site inherits permissions from its parent. (Parent Website Name).

Implementation through SharePoint Object Model

Obviously, it is the SiteCollection which is the eventual security boundary. All SPWeb inherit the users from SiteCollection, unless of course such inheritance has been broken. Similarly, there are two properties representing groups, which are Groups and SiteGroups. You can probably guess what these are: the groups are also inherited from parent to SPWeb. As before, both Groups and SiteGroups represent collections of the SPGroup object.

Finally, there is also a property called Roles. This is a collection of type SPRole. However, as
mentioned earlier, that SPRole has been deprecated since SharePoint 2007. To replace these, two new objects have been introduced, namely SPRoleDefinition and SPRoleAssignment, which can be seen in the class diagram in Figure

· Get the SharePoint Groups from the SharePoint site

string url = http://nmadan:3500; using (SPSite site = new SPSite(url)){ using (SPWeb web = site.OpenWeb(url.Replace(site.Url, string.Empty))) { foreach (SPGroup group in web.Groups) { Console.WriteLine(“Group Name :- ” +group.Name + ” Group Owner :- “+ group.Owner ); } } }

· Get the SharePoint Users from the SharePoint site

string url = “http://nmadan:3500”; using (SPSite site = new SPSite(url)) { using (SPWeb web = site.OpenWeb(url.Replace(site.Url, string.Empty))) { foreach (SPUser user in web.Users) { Console.WriteLine(“User Name :- ” + user.Name + ” User Login :- “+ user.LoginName ); } } }

· Get the All SharePoint Users from the SharePoint site it provides all the SPUsers(excluding SharePoint Group) and Domain Groups

string url = “http://nmadan:3500”; using (SPSite site = new SPSite(url)) { using (SPWeb web = site.OpenWeb(url.Replace(site.Url, string.Empty))) { foreach (SPUser user in web.AllUsers) { Console.WriteLine(“User Name :- ” + user.Name + ” User Login :- “+ user.LoginName ); } } }

· Get the all the RoleAssignment in the SharePoint

string url = “http://nmadan:3500”; using (SPSite site = new SPSite(url)) { using (SPWeb web = site.OpenWeb(url.Replace(site.Url, string.Empty))) { SPRoleAssignmentCollection roleassigments = web.RoleAssignments; foreach (SPRoleAssignment roleAssign in roleassigments) { Console.WriteLine(“RoleAssignment Name :- ” + roleAssign.Member + ” RoleAssignment Parent :- ” + roleAssign.Parent); } } }

· Get the all the RoleDefinition and its Base Permission in the SharePoint site

string url = “http://nmadan:3500”; using (SPSite site = new SPSite(url)) { using (SPWeb web = site.OpenWeb(url.Replace(site.Url, string.Empty))) { SPRoleDefinitionCollection roleDefinitions = web.RoleDefinitions; foreach (SPRoleDefinition roleDef in roleDefinitions) { Console.WriteLine(“RoleDefinition Name :- ” + roleDef.Name + “Base Permission :- ” + roleDef.BasePermissions); } } }

· How to create a new RoleDefinition in the SharePoint site

string url = “http://nmadan:3500”; using (SPSite site = new SPSite(url)) { using (SPWeb web = site.OpenWeb(url.Replace(site.Url, string.Empty))) { SPRoleDefinition customPermissionLevel = new SPRoleDefinition(); customPermissionLevel.Name = “Manager”; customPermissionLevel.Description = “Can view only view pages, list items, and documents.”; customPermissionLevel.BasePermissions |= SPBasePermissions.ViewListItems | SPBasePermissions.OpenItems | SPBasePermissions.ViewVersions | SPBasePermissions.ViewFormPages; web.AllowUnsafeUpdates = true; web.RoleDefinitions.Add(customPermissionLevel); web.Update(); } }

· How to add a new RoleAssignment to user or group in the SharePoint site

string url = “http://nmadan:3500”; using (SPSite site = new SPSite(url)) { using (SPWeb web = site.OpenWeb(url.Replace(site.Url, string.Empty))) { SPRoleDefinition customRoleDefinition = web.RoleDefinitions[“Managers”]; SPUser user = web.Users[“ASIAPACIFIC\madanna”]; SPRoleAssignment assignment = web.RoleAssignments.GetAssignmentByPrincipal(user); assignment.RoleDefinitionBindings.Add(customRoleDefinition); web.AllowUnsafeUpdates = true; assignment.Update(); web.Update(); } }