Authorization Object Relations

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

An individual user (SPUser) gains access to a Windows SharePoint Services 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), while in a domain group or SharePoint group role assignment, the domain group or SharePoint group is the principal.

Users, Groups, and Principals

Windows SharePoint Services supports both Windows users (for example, DOMAIN\User_Alias) and external users (via pluggable authentication). The user identity is maintained by the identity management system (for example, Active Directory directory service). The user profile, which includes their display name, e-mail address, and other information, is scoped to the site collection level. Changing a display name has impact on the entire site collection.

A group is a collection of users through which Windows SharePoint Services manages security. User-based management is simple and 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 one, the Read role for list two, as well as the Design role for list three. 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 both the manageability and scale problems of user-based permissions management. Group-based management may be more abstract or harder to conceptualize, but it allows easier management of complex sites with many uniquely secured objects, such as 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.

Windows SharePoint Services supports two kinds of groups: domain groups and SharePoint groups. Domain groups remain outside Windows SharePoint Services control; users cannot use Windows SharePoint Services to define, browse, or modify domain group membership. SharePoint groups are scoped to the site collection level, and they can only be used within the site collection, whereas domain groups can be used anywhere within the scope of the Active Directory directory service.

A principal is a user or group 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 Windows SharePoint Services is keeping 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

The following figure shows a high-level view of the Windows SharePoint Services 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.

A scope represents a uniquely secured object or set of objects. In Windows SharePoint Services 2.0 there were only two kinds of scopes: site and list. In Windows SharePoint Services 3.0 there are folder and item level scopes as well.

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. In addition, each role definition (SPRoleDefinition) can 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 one and readers on list two 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 and Administrator roles 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 only has 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, Windows SharePoint Services 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 that 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, Windows SharePoint Services 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 Windows SharePoint Services knows what each user or group is allowed to do within the given scope.