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.
A New Way of Seeing Things
You might think you have only two ways to implement item-level security: Undertake a significant development effort to extend SharePoint or integrate a third-party product that provides the desired level of capability. However, the simplest—and least-expensive—approach is to revise your thinking about what a SharePoint item is and what securing an item means.
A SharePoint item is more than a piece of content: It's also the SharePoint metadata (e.g., an author name, a category value) that's attached to the item, and it's the page and Web Parts that surround the item. For example, a document workspace might include the members Web Part that lists the workspace users who will collaborate on the document. Accepting this macro view of content requires that you think carefully about how to structure your information architecture.
Structure your SharePoint Portal Server areas so that content that requires similar access levels reside in the same area. Create an area security hierarchy in which permissions become more restrictive as you move deeper into the hierarchy. For example, place company-wide communications in an area to which all employees have access. Below this area, create a subarea that contains HR department data to which all HR employees have access; below that subarea, create another subarea that contains more-sensitive HR data to which only a subset of HR employees have access. For more granular control, configure permissions on Windows SharePoint Services lists and document libraries. Think of an area and a list or document library as analogous to a file-system folder, to which you assign permissions to protect the folder's content.
To make secured Windows SharePoint Services content appear in SharePoint Portal Server, use portal listings; to limit exposure to content listings, use audience targeting. An audience is a named rule or set of rules based on AD attributes (e.g., group membership) or SharePoint Portal Server profile attributes (which might or might not be mapped to AD attributes). You can use audience targeting to limit who can see a listing, by assigning that audience the ability to see the listing. You can also use audience targeting to limit who can see a Web Part. Audience targeting isn't an access-control measure. Rather, it increases the difficulty of finding a list or a Web Part for users who don't satisfy the rules assigned to the targeted audience.
Staying within the bounds of SharePoint security architecture is the easiest and cheapest approach for dealing with the item-level security gap. However, the challenge to making this approach work is staying on top of your organization's information architecture and security policies. If your organization has restrictive document-management requirements, you can integrate SharePoint with another Enterprise Content Management (ECM) product such as EMC Documentum. SharePoint provides the UI and collaboration components, and the ECM product provides, among other things, a document repository that supports item-level security. However, this approach has several disadvantages:
- The ECM product replaces, rather than augments, SharePoint's somewhat limited content-management infrastructure.
- The ECM product adds significant cost to a SharePoint implementation.
- The ECM product isn't easy to integrate into SharePoint and thus requires a dedicated resource or third party (e.g., Vorsite) to provide the integration.
- A simple upgrade path to the next version of SharePoint might not exist.
Not Perfect—but Definitely Better
As any IT professional can attest, there are no perfect software products. Every sophisticated application has some sort of shortcoming. Similarly, commercial software products can meet only a subset of the user community's needs, especially when the user base is large and diverse. Identifying gaps and proposing solutions is an essential part of assessing or working with a product. With SharePoint's increasing popularity and importance, finding and dealing with SharePoint Portal Server's and Windows SharePoint Services' gaps are vital steps in making the products succeed in your environment. For more gap-busters, see "Get Past the Gaps in SharePoint," February 2006, InstantDoc ID 48919, and look for upcoming articles on the topic. Also, let us know when you find SharePoint shortcomings, and we'll try to help you find the solutions. Send an email (with the subject line "SharePoint Gaps") explaining any gaps to Ethan Wilansky (ewilansky@windows itpro.com).
