The SharePoint object model also implements security
all the way through.You should have a site collection with three users, namely the
administrator, John Doe, and Jane Doe set up in your SharePoint
environment. John Doe and Jane Doe are restricted users in your site
collection. If you do not have such a site collection, please create
such a site collection.
Now examine the class diagram shown in Figure 1.
Figure 1. SPMember based objects in the SharePoint object model
This is a class diagram of
some standard SharePoint objects available inside the SharePoint object
model. As you can see from this object model, there are two internal
classes, namely SPMember and SPPrincipal. SPPrincipal inherits from
SPMember. In short, anything that can be given a security right within
SharePoint in one way or the other inherits from the SPMember base
class. Therefore, there are SPGroup, SPUser, and SPRole. These three
objects are what can be given permissions inside of SharePoint. As you
will see shortly, SPRole has been deprecated since SharePoint 2007.
Now examine the class diagram shown in Figure 2.
At the heart of this class
diagram is an internal abstract base class called SPSecurableObject.
Anything inside of SharePoint that be given a permission is an
SPSecurableObject. Any SPSecurableObject implements the ISecurableObject
interface. Examples of such object are SPWeb, SPSite, SPList, and
SPListItem. Let's take the example of SPWeb. SPWeb inherits from
SPSecurableObject. Therefore, it is an object that permissions can be
given to. The next question is how exactly do you give permissions to
this object? The SPWeb object has different properties on it. These
properties represent the roles (SPRole), the group's (SPGroup), and the
user's (SPUser) that have access to this particular SPWeb. Note that I
haven't talked about what level of access yet. I'll discuss this
Figure 2. SPSecurableObject based objects in the SharePoint object model
Let's take the example of
users. There are three properties representing the users that have
access to this particular SPWeb. They are SiteUsers, Allusers, and
Users: Users explicitly added to the SPWeb.
AllUsers: All users that have anything to do with the SPWeb. Users plus users SharePoint saw through Groups.
Site Users: Aggregation of AllUsers at the SiteCollection level.
The SiteUsers is a superset
of AllUsers is a super set of Users. And all three of these are a
collection of the SPUser object. This can be seen in Figure 3.
Figure 3. The relationship between Users, AllUsers, and SiteUsers
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
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 4.
In order to understand these
two objects, visit your site collection. In your site collection, go to
site settings, and then under users and permissions click site
permissions. You should see the various groups and users added to this
SiteCollection, along with their associated permission levels. This can
be seen in Figure 5.
Figure 4. The permissioning model in SharePoint 2010
Figure 5. The various SharePoint groups
In the ribbon, you will also
find a button called permission levels, so click that button. Clicking
this button will show you the defined permission levels inside a
SiteCollection, as shown in Figure 6.
Figure 6. The various permission levels
Click the full control link
and it should show you the various permissions you can configure in any
SharePoint permission level. Some of these permissions can be seen in Figure 7.
Figure 7. Details of a permission level
Specifically, in the
object model, the permissions you see as check boxes are represented by
an Enumerator called SPBasePermissions. SPRoleDefinition represents the
levels such as "Full Control", "Contribute", while a Role Assignment
contains a collection of Role Definitions.
Any object that inherits
from SPPrincipal can be assigned a SPRoleAssignment. This becomes
clearer when you observe all the objects in one single class diagram, as
shown in Figure 8.
Figure 8. Overall security-related object model in SharePoint 2010
As you can see, the
SPRole assignment object has a property on it called Member that points
to an SPPrincipal. Therefore, an SPPrincipal such as an SPUser called
"smalik", can have a role assignment that points you to two
SPRoleDefinitions, "Full Control" and "Design", thereby giving you a
union of SPBasePermissions between Full Control and Design. Please read
the last sentence one more time because it is incredibly important to
You can verify all the preceding by running the code shown in Listing 1 on your SharePoint site collection.
Example 1. Code to Browse the Security Setup of Your Site Collection
private static void BrowseSecurity()
using (SPSite site = new SPSite(siteUrl))
SPWeb web = site.OpenWeb();
foreach (SPUser user in web.Users)
Console.WriteLine("\n\n All Users:");
foreach (SPUser user in web.AllUsers)
Console.WriteLine("\n\n Site Users:");
foreach (SPUser user in web.AllUsers)
foreach (SPRole role in web.Roles)
Console.WriteLine("\n\n Roles Definitions:");
foreach (SPRoleDefinition roledef in web.RoleDefinitions)
Console.WriteLine("\n\n Roles Assignments:");
foreach (SPRoleAssignment roleA in web.RoleAssignments)
Console.WriteLine("The following Role definition bindings exist for " +
foreach (SPRoleDefinition roledef in roleA.RoleDefinitionBindings)
foreach (SPGroup group in web.Groups)