Access users, user groups, and permissions for the SharePoint server-side object model (Part 1)

(i) overview

The SharePoint permissions system is a relatively important part of the entire SharePoint system, and the authority system is divided into two main parts: Authentication and authorization.

The main problem of authentication is to determine whether the lander is legitimate, and which user he is, and what SharePoint has to do with the user and user groups involved. SharePoint supports multiple authentication methods, from the most basic Windows Integrated authentication to various forms certifications, and adds a claims-based (Claim Based) authentication method to SharePoint 2010, as well as some related services, Allows multiple authentication methods to be used on the same site. However, the setting of the authentication method is not within the scope of this book.

The main problem with authorization is to determine what permissions a user has on an object, such as a site, list, and so on, in other words, what the user can do on this SharePoint site. The objects that are related to SharePoint include permissions, permission levels, and permission assignments.

Before introducing the object model related to permissions, let's review the licensing architecture of SharePoint. The following diagram shows the structure and relationship of the authorization architecture in SharePoint (this section has no essential difference between 2010 and 2007):

As you can see, in the SharePoint privilege system, the central position is the permission assignment (role Assignments), which has three groups of objects around the permission assignment:

1. Range (Scopes)

The scope specifies what object to assign permissions on. In SharePoint, any object that can assign permissions directly or indirectly inherits the Spsecurableobject class, and the methods and properties for that class are described in detail later (in 2007, these objects implement the Isecurableobject interface, However, in fact, the Spsecurableobject class in 2010 also implements this interface. In SharePoint, the interface classes are implemented including SPWeb, SPList, and SPListItem. That is, objects that you can assign permissions to in SharePoint include sites, lists, list entries (including, of course, documents in document libraries, as well as lists, folders in document libraries).

By default, permissions assignments for SharePoint have an inheritance relationship in scope. The permissions assigned to the subsite are the same as the parent site, and the permissions assigned to the list are the same as the site where they are located, with the same permissions assigned to the entries and documents as the list and document libraries, and, if the folders are included, the entries/documents within the folder are assigned the same permissions as the folder. However, this inheritance is allowed to be broken by the user (in the Permission Settings page, click "Stop Inheriting Permissions"), after breaking the inheritance relationship, any permission assignment to its parent object will no longer affect the end of the inherited child object, and the child object can also choose to re-inherit the parent object's permission assignment at any time-- This, of course, means that the permission assignment settings for the child object itself are destroyed and the permissions are reassigned according to the settings on the parent object.

2. User Token (username tokens)

In SharePoint, users who can be assigned permissions include regular users, SharePoint user groups, and AD security groups (equivalent to "roles" in ASP. NET membership). Therefore, when assigning permissions, the administrator can have multiple choices (assuming that the user is authenticated using AD):

(1) Assigning permissions directly to a user;

(2) Assigning permissions to a SharePoint user group and adding users who need to assign permissions to different groups of users depending on permissions (in the interface of SharePoint permissions assignment shown in Figure 3-18, you can see clearly how these two permissions are assigned);

(3) Add the user to the security group in AD, then add the security group to SharePoint and assign the permissions;

(4) Join the security group that contains the user to the SharePoint users group.

In general SharePoint projects, it is not recommended to assign permissions directly to users, which can cause confusion and trouble in later rights management, so it is recommended to use methods (2) to (4). However, in some places, permissions can only be set to specific users, such as site collection administrators.

3. Permission Control List (ACL)

Permissions control in SharePoint is divided into two levels: permissions (Permission) and permission levels (Role Definition).

Permissions refer to specific user behavior, such as creating list entries, viewing list entries, managing sites, creating subsites, approving entries, and so on.

A permission level is a set of permissions organized by application, such as read, view only, participate in discussions, full control, and so on, each of which includes the same or different combinations of permissions. As you can see from Figure 3-17, in SharePoint, the assignment of permissions is done only through permission levels.

The permission level is defined in the site, and by default, the permission level of the subsite is the same as the parent site definition and inherits the definition of the parent site. Of course, the administrator can also choose to end this inheritance relationship, which is similar to the inheritance of the end permission assignment. However, if you need to break the inheritance relationship of permission level, the precondition is to break the inheritance relationship of permission assignment first.

In summary, the authorization system in SharePoint can be generalized as: on An object, assign a group of permissions to a user (or group of users).

Access users, user groups, and permissions for the SharePoint server-side object model (Part 1)