The SharePoint Security 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.

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.
There are three properties representing the users that have access to this particular SPWeb. They are SiteUsers, Allusers, and Users.
• 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.
• SiteUsers: 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

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

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

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

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

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

More Here

Courtesy:http://kolliparachandra.wordpress.com/2010/12/06/the-sharepoint-security-object-model/