Microsoft SharePoint Portal Server 2003 and Windows SharePoint Services 2.0 continue to grow in popularity, and many Exchange Server admins are finding themselves in charge of designing, implementing, deploying, and managing a system based on one or both SharePoint products. Microsoft and others have done a great job of touting the strengths of SharePoint Portal Server and Windows SharePoint Services. Our goal is to inform you of these products' weaknesses—such as lack of item-level security—and give you potential solutions. Be aware that in this article, the term SharePoint refers to both SharePoint Portal Server 2003 and Windows SharePoint Services 2.0.
What's the Problem?
SharePoint security is a mix of varied capabilities at both the portal level (through SharePoint Portal Server) and the site level (through Windows SharePoint Services). What SharePoint doesn't include is the ability to set specific permissions on an individual piece of content. You can find mention in the product documentation and UI of item-level security that applies to a SharePoint Portal Server list, but the feature is primitive: Basically, a user who has Administrator permission to the list can use the feature to control which list items other users can read and edit. (Figure 1 shows the Item-level Permissions section of a list item's Properties screen.) SharePoint doesn't provide the capability to control the permissions assigned to a single list item or piece of content. Before considering the item-level security gap and possible solutions, it's important to understand the overall SharePoint security architecture and how SharePoint Portal Server security differs from Windows SharePoint Services security.
Roles. SharePoint includes a security object called a site group, or role. A role contains a set of permissions that together impart a general capability that serves a function in SharePoint. Although you can use the UI to see SharePoint roles, a more direct way to list all the default SharePoint roles is to use the stsadm.exe administration tool. For example, to enumerate all roles defined on a portal named portal01, type
stsadm -o enumroles -url
http://portal01
As the output in Figure 2 shows, two default SharePoint roles are Contributor and Web Designer. A Contributor can add content to document libraries and lists; a Web Designer has permission to modify the look and feel of a Share-Point Portal Server area or a Windows SharePoint Services site. You can't customize the permissions assigned to the Guest and Administrator default roles or delete these roles. You can modify the permissions assigned to other default roles, but we recommend that you create new roles and modify them as necessary. Doing so will preserve the default rights assigned to the out-of-the box roles, which you can use as templates for defining new roles.
To make a role functional, you assign user accounts or groups to the role. Wherever a role is assigned in the SharePoint hierarchy, the user is granted permission to perform the tasks associated with that role. If your SharePoint implementation isn't part of an Active Directory (AD) domain, the user and group accounts must be defined on the computer that runs SharePoint. If your SharePoint server or SharePoint Web farm is part of a domain, you can associate either local user and group accounts or AD user and group accounts to roles. Although you can assign SharePoint permissions directly to groups or to users, Microsoft recommends that you assign groups to roles and add users to those groups.
Applying security. Now that you understand the relationship between roles, users, and groups, let's consider how you can apply security in SharePoint. Table 1 lists and describes each SharePoint element (aka security surface) to which you can apply security. (For complete descriptions of these elements, refer to the "Windows Share-Point Services Administrator's Guide" at http://tinyurl.com/3hnup. You can navigate to the SharePoint Portal Server Administrator's Guide from the All Programs, SharePoint Portal Server program group.) On each security surface, you can assign a group or a user account to a role. To simplify the rest of the discussion, we'll refer to groups and user accounts in this context as security principals.
When you assign a security principal a role on a SharePoint security surface that has child elements, the child inherits the permission settings of its parent. For example, a SharePoint Portal Server subarea inherits the permission settings of its parent area. In Windows SharePoint Services, a subsite, workspace, or list inherits the permission settings of its parent. This inheritance continues through the hierarchy, unless you block it by explicitly assigning security principals to a security surface.
Now here's the strange part: You assign roles to security principals at the very top of the SharePoint Portal Server hierarchy, and those role assignments then flow down to any portal subarea for which inheritance is allowed and not blocked by explicit permissions assigned to a subarea's parent. In Windows SharePoint Services, you create roles in a site collection from the Top-Level Site Administration-Manage Site Groups screen. After you create the roles, they can be inherited down the site-collection hierarchy. But in Windows SharePoint Services, you also can assign roles explicitly to security principals at any place in the hierarchy. SharePoint Portal Server allows only for role inheritance.
This role-configuration inconsistency between SharePoint Portal Server and Windows SharePoint Services doesn't represent a gap in itself, but the result is that if you need to add a role in SharePoint Portal Server and you want to use that role somewhere in the SharePoint Portal Server hierarchy, you have to enable inheritance on the subarea to allow the role to appear in that area. You can explicitly assign a security principal in a SharePoint Portal Server area by assigning a set of permissions, which might be a convenient method but which is more difficult to manage than inheritance because it leads to a more-complex security configuration.
The primary differences in security architecture between SharePoint Portal Server and Windows SharePoint Services have to do with where and how you apply security. Whereas SharePoint provides explicit application of role, group, and user-based security for SharePoint Portal Server areas, Windows SharePoint Services sites, or Windows SharePoint Services lists, neither product extends the same security capability at the item level.