SharePoint Portal Server Security Architecture

SharePoint Portal Server provides significant new features for controlling access to documents, in addition to a state machine for structured approval of a document. When an event occurs with a state machine, the object responds by changing its state to reflect the new history of the object. SharePoint Portal Server uses a complex and extensible permissions system that builds upon the traditional Windows NT security model, while providing the ability to control access to operations in a way that does not conflict with the publishing model.

Viewing Role States and Actions

The following table shows the document states and user actions and which roles can perform these actions in the given state. The list of allowed roles is the following:

• Lock Holder. The last person to check out the document
• Submitter. The person who submitted the document for approval.
• Reader. A person viewing the document.
• Author. A person creating or modifying the document.
• Approver. The current approver of the document (as opposed to all the members of the approver role).
• Coordinator. A person who specifies security for a given folder or document.

These roles are not visibly apparent in the user interface but describe how SharePoint Portal Server modifies access as a document traverses the publishing model. From the perspective of the user, SharePoint Portal Server features three roles: Reader, Author, and Coordinator. In addition, you can also specify a list of approvers for a folder within the workspace.

The following table shows the different states of a document during the publishing model, the various actions that can be performed, and who is given the access rights on the source folder to perform the action.

Role States and Actions

State/Action	Created/ Checked Out	Checked In	Checked Out	Under Approval	Approved
Save			Lock Holder
Check In	Creator		Lock Holder
Check Out		Author; Coordinator			Author; Coordinator
Undo Check Out			Lock Holder; Coordinator
Submit		Author; Coordinator
Approve				Approver
Reject				Approver
Bypass Approval				Coordinator
Cancel Approval				Submitter, Coordinator
Move	Creator; Coordinator	Author; Coordinator	Lock Holder		Author; Coordinator
Copy	Creator; Coordinator	Reader; Author; Approver; Coordinator	Reader; Author; Approver; Coordinator	Reader; Author; Approver; Coordinator	Reader; Author; Approver; Coordinator
Delete	Creator; Coordinator	Author; Coordinator	Lock Holder		Author; Coordinator
Read Draft	Creator; Coordinator	Author; Coordinator	Author; Coordinator	Author; Approver; Coordinator	Author; Approver; Coordinator
Read Approved		Reader; Author; Coordinator	Reader; Author; Coordinator	Reader; Author; Approver; Coordinator	Author; Coordinator

Defining the Publishing Model

Figure 8.4 presents a simplified publishing model for SharePoint Portal Server. In addition, it demonstrates the path a document traverses from a published state to a newly published version.

Figure 8.4. Publishing model

In this illustration, a reader or approver may view the last approved version (1.0), while the author is working on the latest unapproved version (working copy) of a document. The current author, as the person who checked the document out, is the lock holder and consequently has the working copy of the document. As the author checks in the document, SharePoint Portal Server assigns the version number 1.1 to it. After publishing and approval, the document becomes version 2.0.

Enabling Role Membership Inheritance

Many SharePoint Portal Server deployments incorporate a large number of folders, while requiring a relatively small number of distinct security policies. SharePoint Portal Server allows you to enable inheritance of role membership so that coordinators can manage security policies across large numbers of folders by making changes to role memberships on a single parent folder. You can configure every folder to adopt the security settings of its parent folder (similar to the ACL inheritance provided in Windows 2000). When a folder inherits security from its parent folder, all role memberships on the folder match the parent folder. It is not possible to alter role membership on the folder. The server applies all changes to role membership on the parent to inheriting children at the time you change the security settings for the parent folder.

If you choose to cancel inheritance, you have the option of copying the role membership from the parent folder, or removing all role memberships from the folder. If you enable inheritance after it is cancelled, SharePoint Portal Server completely replaces the current role membership with the role membership of the parent. When you create a new folder, it inherits security settings from its parent by default.

Because the state of approver is not a security role, subfolders do not inherit approval policies: Subfolders inherit neither the role settings nor the approval topology. You must specify approval policies on each folder.

It is possible to reset the inheritance on all subfolders. This resets inheritance recursively on all descendants. Resetting the security on subfolders is only successful on those folders for which you are assigned the role of coordinator.

Viewing Folder Hierarchies

In order to discover a document by browsing the folder hierarchy, the user must be a member of at least one role on the parent folder. In order to view a list of subfolders within a folder, the user must be a member of at least one role on both the parent folder and the subfolder.

In order to list the contents of a folder, the user must be assigned to a role on the folder. SharePoint Portal Server modifies the list of all items in that folder so that the user only sees items that he actually has access to read. In other words, any documents for which a user is denied access or any subfolders on which the user has no role membership are not visible in the list of contents. Search results only include documents that users are granted permission to view and access.

As described previously, local administrators always have implicit read access to all contents.

Assigning Default Role Membership

By default, when you create a workspace, SharePoint Portal Server assigns the following default role membership for all visible folders:

• Reader: Everyone
• Coordinator: Workspace Creator

Selecting Users from Directory Sources

When roles are used, the coordinator populates each role's membership list with actual Windows NT users and groups in the specific domain. You select users, groups, and roles from the standard Windows NT user picker. You can select users and groups from the following locations.

Windows 2000 Active Directory Domains

The contents of a role's membership list are the users and groups from the Windows 2000 directory structure.

Windows NT 4 Domains

In a Windows NT 4 domain, Windows stores SIDs in the security accounts manager (SAM) database. When a coordinator needs to add users to a role, she selects users from the directory. In this case, SharePoint Portal Server lists the user and group SIDs from the SAM database and allows the person to place them in the Role membership list.

The Windows NT 4 SID structure is the same as Windows 2000 SIDs. No special handling needs to occur for users and group collected from a Windows NT 4 domain.

Local Windows NT Accounts

In addition to domain groups, coordinators may select from local groups and users on the server running SharePoint Portal Server. This option is particularly helpful in an environment where you do not employ Windows NT domains. In this situation, SharePoint Portal Server collects and authenticates the username and password against local accounts maintained on the local SharePoint Portal Server computer running Windows 2000.

In general, you should not allow local user or group accounts to secure content because other servers running SharePoint Portal Server cannot resolve local accounts on individual computers. Consequently, content secured by using local accounts on other servers cannot be included in an index nor viewed by users on the dashboard site.

Authenticating with SharePoint Portal Server

SharePoint Portal Server workspace access is restricted to valid Windows NT users and groups, whether they are domain users or local server users. When you deploy SharePoint Portal Server within a Windows NT domain and the user logs into the domain, SharePoint Portal Server uses the domain security services for authentication. This enables single logon for users. When you deploy SharePoint Portal Server and you do not implement Windows NT domains, SharePoint Portal Server collects and authenticates the username and password against accounts maintained on the computer running SharePoint Portal Server.

Windows 2000 assigns anonymous users an SID that allows them to be included in ACLs. Consequently, you can also assign anonymous accounts to roles. However, if you choose to enable anonymous accounts, Windows 2000 treats all users as anonymous users. It is recommended that you create a separate virtual server, or vroot, for this type of access.

For more information about creating a separate virtual server, see Chapter 12, Deploying SharePoint Portal Server in an Extranet Environment.

Ensuring Dashboard Site Security

SharePoint Portal Server relies on Internet Information Services (IIS) Web server to enforce security. SharePoint Portal Server supports URL access to the Web Storage System. All access to the dashboard site is through a vroot, controlled by IIS, which uses Windows NT permissions to enforce security. Windows NT requires the basic set of rights that are embodied by the Web Storage System. IIS relies on the underlying storage system, such as NTFS or the Microsoft Web Storage System, to provide ACLs that contain the users who have access to the requested object.

Ensuring Search Security

The user search experience requires security in two aspects of search processing:

• Default content access account. SharePoint Portal Server crawls external content within the context of a user account. You provide a default content access account for SharePoint Portal Server to use to access external content. In addition, you can specify an access account for an individual content source. This account information is stored as a property of the crawl seed item.
• Search results access. In search results, that is, logical views of documents, a user cannot view a document or folder unless he has access to read the file.

Unless an appropriate trust relationship is established, the default content access account or the access account for a particular content source must be a member of the appropriate group in the domain where the content is located in order to crawl the content and include it in an index. In addition, the user must also be a member of the appropriate security group in order to view the content.

In a native-mode environment, universal groups can facilitate the security administration. In a mixed-mode environment, you must establish the appropriate trust relationship as well as implement a compatible group strategy.

Ensuring Access to Security Tasks

Coordinators specify content security and assign roles. The predefined set of roles provides the appropriate level of control and flexibility.

SharePoint Portal Server Administration

A computer running SharePoint Portal Server may contain one or more workspaces. When you create a workspace, SharePoint Portal Server prompts you to designate a workspace owner. SharePoint Portal Server assigns this owner to the coordinator role for the workspace.

Workspace Lockout

SharePoint Portal Server allows coordinators to control the access to a document for both reading and viewing. Someone who does not have access to a document or folder cannot discover its existence through search or folder browsing. In addition, it is possible to configure the security membership on a folder to be completely distinct from the role membership of the parent folder. As a result, you could configure security so that no users can view the secured object. In this situation, it would be impossible to change the role membership on the folder again, because it would be impossible for anyone to browse to the parent folder and access the Properties page of the subfolder to modify the security settings.

To address this possibility, SharePoint Portal Server assigns the local Administrators group the permissions to read and browse every document and every folder in all workspaces. This is a nonconfigurable, nonrevocable right of the local Administrators group. It takes precedence over the No Access role on individual items. The local Administrators group also has the permissions to specify role membership on all folders and all documents. Therefore, if a folder becomes inaccessible due to the scenario outlined previously, anyone who is a member of the local Administrators group on the server can resolve the problem. Any user who is a member of the local Administrators group can assign role membership on all files and folders, regardless of the user's role membership on specific folders

SharePoint Portal Server does not grant a member of the local Administrators group full privileges for all coordinator operations. For example, although a member of the local Administrators group can attempt operations such as changing Web Part settings or layout of the dashboard site, those operations silently fail. SharePoint Portal Server does not report the failures. To complete these operations successfully, the local Administrator must add herself to the coordinator role on the appropriate folder.