Authorization Object Relations
Applies to: SharePoint Foundation 2010
An individual user (SPUser) gains access to a Microsoft SharePoint Foundation object directly through an individual role assignment, or indirectly through membership in either a domain group or a SharePoint group (SPGroup) that has a role assignment. In a direct role assignment, the user is the principal (SPPrincipal). In a domain group or SharePoint group role assignment, the domain group or SharePoint group is the principal.
Users, Groups, and Principals
SharePoint Foundation supports Windows users (for example, DOMAIN\User_Alias) and external users (through pluggable authentication). The user identity is maintained by the identity management system (for example, the Active Directory directory service). The user profile (which includes the user’s display name, e-mail address, and other information) is scoped to the site-collection level. Changing a display name affects the entire site collection.
A group is a collection of users through which SharePoint Foundation manages security. User-based management is straightforward for simple sites, but becomes more complex as the number of uniquely secured resources grows. For example, a user may have the Contribute role for list 1, the Read role for list 2, and the Design role for list 3. This model does not scale well if there are, for example, 50,000 users—which would result in access control lists (ACLs) being 50,000 access control entries (ACEs) long on every uniquely secured object.
Groups provide an answer to the manageability and scale problems of user-based permissions management. Group-based management may be more abstract or more difficult to conceptualize, but it enables easier management of complex sites with many uniquely secured objects. For example, when adding a user to a group that has already been granted the appropriate role on various objects in the system. The permissions checking for groups scales better because far fewer group ACEs need to be stored.
SharePoint Foundation supports two kinds of groups: domain groups and SharePoint groups. Domain groups remain outside SharePoint Foundation control; users cannot use SharePoint Foundation to define, browse, or modify domain group membership. SharePoint groups are scoped to the site-collection level, and they can be used only within the site collection. Domain groups can be used anywhere within the scope of the Active Directory directory service.
A principal is a user or group that is used to control security. If you add a user to a site, the user is the principal, but if you add a group to the site, the group is the principal. The key to scaling security in SharePoint Foundation is to keep the number of principals per scope reasonable. By using groups, a smaller number of principals can be used to grant access to a much larger number of users.
High-Level View of Object Relations
Figure 1 shows a high-level view of the SharePoint Foundation security management system in a logical database diagram. Each box represents a security object in the system. The lines represent relationships between the objects. The 1 and N notation represents the type of relationship. The figure shows how permissions data is structured into a user token and an ACL.
Figure 1. Authorization object relations
.gif "Authorization object relations")
A scope represents a uniquely secured object or set of objects. You can scope to site, list, folder or item level.
Users and groups have a many-to-many relationship (N to N). Each user (SPUser) can be a member of multiple groups, and each group (SPGroup) can contain multiple users.
Rights and role definitions also have a many-to-many relationship (N to N). Each right (SPBasePermissions) can be part of multiple role definitions. For example, the Insert List Items right is included in the Contributor, Designer, and Administrator role definitions. Each role definition (SPRoleDefinition) can also contain multiple rights. For example, Contributor includes the rights for inserting, updating, and deleting list items.
Role definitions and role assignments (SPRoleAssignment) have a one-to-many relationship (1 to N). Each role definition is used in multiple role assignments. The readers on list 1 and the readers on list 2 may be different, but their role assignments can share a single role definition: Reader.
Users or groups and role assignments have a many-to-many relationship (N to N). Each user or group can be a member of multiple role assignments on a given object. For example, a user may have both the Designer role and the Administrator role on the same object.
Scopes and role assignments have a one-to-many relationship (1 to N). Each scope has multiple role assignments, but each role assignment has only one scope. For example, one user may be a reader on the Events list, and another user may be a contributor on the Events list, but neither of these role assignments applies to the Announcements list. The only way for two lists to share the same role assignment is by inheriting their permissions from the parent container, in which case the security scope is the container, not the two lists.
User Tokens and Access Control Lists
To make checking permissions faster, SharePoint Foundation implements user tokens and ACLs in its security model. The user token identifies the authentication process applied to a user. A Windows user has a complex token: a unique string for the user (SID) and a list of all the Windows domain groups for the user, for example, DOMAIN\Department 15688. A user who does not have Windows authentication may have a very simple token with a unique string for the user name, or a complex token with group/role membership just as expressed in Windows authentication. SharePoint group membership for each user is expressed through a user token so that, by reading the user token, SharePoint Foundation identifies all groups for the current user.
An ACL is a binary object that determines the rights that users and groups have on a given object. An ACL consists of multiple ACEs, each security principal (user or group) being one ACE in the ACL. Rights, role definitions, and role assignments are structured into an ACL for each scope, so that SharePoint Foundation knows what each user or group is allowed to do within the given scope.