By Dan Holme
Office & SharePoint Pro
Community Manager
The SharePoint Permissions Model: Follow the Permissions Trail
(Part 1)
A question came up on a SharePoint email list last week that caused me to take a moment to document exactly what makes things tick in SharePoint, from a security standpoint. The gist of the question was, "What makes the 'New' button appear?" (It wasn't appearing correctly). I hope that a close examination of the answer to that question will help you better understand the interaction between permissions, identities, SharePoint configuration, and client configuration. The New Button Doesn't Appear 
Figure 1: The New button doesn't appear If you don't see a "New" button, it most likely means you don't have permission to add items. Just how does that permission end up applying to you? Web Application User Permissions
The Web application is the fount of all permissions. From Central Administration's Application Management page, click the "User permissions for Web application" link. There, you can specify the granular permissions that will be available within the Web application. By default, all SharePoint permissions are available for a new SharePoint Web application, including the Add Items permission. 
Figure 2: The Add Items permission in the Web application's Permission Site Permission Levels
The Web application setting shown in Figure 2 states that the Add Items permission will be available to sites within the Web application. It doesn't actually do anything. The next step is to use that permission in a site permission level. Permission levels are bundles of granular permissions. If you're used to NTFS permissions, you know that the NTFS Modify permission template includes a handful of granular NTFS permission entries. The same concept applies here: A permission level, such as Contribute, includes a handful of permissions. To define a permission level, go to the Site Settings, Permissions page, click Settings, and choose Permission Levels. As you can see in Figure 3, the Contribute permission level includes the Add Items permission. 
Figure 3: The Contribute permission level By default, all SharePoint sites inherit their permission-level definitions from the top-level site in the site collection. It's recommended that you manage permissions using inheritance, so you would change permission level definitions at the top level site. However, you can also break inheritance and define new permission levels at any site in your site collection's hierarchy. Assigning permission Levels to Identities
Now that you've brought a permission defined at the Web application level into the site, you can assign that permission level to an identity--a user or group. A user can be a user from any authentication provider supported by the Web application. But it's more manageable to put users in groups, and then assign permission levels to groups. Groups can be a group from any role provider supported by the Web application or a SharePoint group, which itself can include other groups or users as members. Figure 4 shows the Edit Permissions page for a user or group. This is where the real action occurs—where you assign a permission to an identity. 
Figure 4: Assigning a permission level to an identity
Although the best practice is to assign permissions to the top-level site in the site collection, and allow inheritance to determine permissions on all subsites, libraries, lists, folders, items, and documents, it's likely that in some scenarios you'll need to assign different permissions to identities for specific sites, libraries, lists, or even individual folders, documents, or items. When you edit the permission of one of those objects, you break the inheritance from the parent container, and you assign one of the available permission levels to an identity.
One of the unfortunate aspects of this "permissions trail" is the terminology. When you assign permissions to an identity, as Figure 4 shows, you're not assigning permissions, per se; you're assigning a permission level. Remember the permission levels are defined at the site level. In Figure 4, on the left side, there is a link that says "View site permission assignments." That really means permission levels. So the UI is a bit misleading, which can make it difficult to remember what the settings are really called and where they are configured, particularly when you are new to SharePoint. By this point in our discussion, you can see how the Add Items permission might end up applying to a user or group. The permission is enabled at the Web application level, included in a site permission level, then assigned to a user or group. But even if you have the Add Items permission, the New button might not appear in a document library. Next week, we'll finish following the permissions trail to the UI. Until next week, all the best! Dan Holme danh at intelliem dot (top level commercial domain) |