Authorization Object Model
Last modified: April 14, 2010
Applies to: SharePoint Foundation 2010
In Microsoft SharePoint Foundation, all object scopes share the same basic permissions management experience. SharePoint Foundation manages permissions through role definitions, which enable a consistent experience at the list, folder, and item level.
The following security objects used in Windows SharePoint Services 2.0 are obsolete, but continue to function for backward-compatibility:
To assign users to roles, use members of the Microsoft.SharePoint.SPRoleAssignment class and the Microsoft.SharePoint.SPRoleAssignmentCollection class. The SPBasePermisssions enumeration, which replaced SPRights, includes additional permissions. The SPBasePermisssions enumeration also includes legacy permissions that map to the same constant values as previous permissions in SPRights. The SharePoint group concept maps to the existing SPGroup object and SPGroupCollection object, which represent cross-site groups.
To create or modify security policies for URL zones, use the following classes and their members:
The concept of a guest role is to accommodate the shared resources in the platform. For example, the theme and navigation structure of the Web site must be used to render the page for a list view. This concept continues in SharePoint Foundation and is extended to include folder-level permissions and list-level permissions.
The SharePoint Foundation object model continues to call this the Guest role for semantic compatibility with the previous object model, although in the user interface the role is now called Limited Access.
Folder and Item Extensions
When a user is granted permissions on a folder, they are also granted the Guest role on the parent list of that folder and on the parent Web site of that list—on every uniquely secured scope above the folder, all the way to the first unique ancestor Web site. This is also true for list items: granting a user permissions on an item also grants that user the Guest role on all parent folders, lists, and Web sites up to the first unique ancestor Web site.
Removing a user from a scope also removes that user from all uniquely secured scopes beneath the current scope. For example, removing a user from a Web site also removes that user from uniquely secured lists in the site.
The only way to remove a user from all scopes is to delete that user from the site collection, which removes the user from all roles in all scopes within the site collection.