Plan for workflow security and user management (SharePoint Foundation 2010)

 

Applies to: SharePoint Foundation 2010

Administrators and workflow developers should plan for the aspects of workflow behavior that relate to security as they develop and configure workflows.

Before deploying workflows in Microsoft SharePoint Foundation 2010 to users, administrators might have concerns about security issues, such as information disclosure or elevation of privilege. This article highlights some aspects of workflow behavior that relate to security and raises other issues for administrators and workflow developers to consider when they plan to configure and develop workflows.

In this article:

• List manager, administrator, and developer roles and responsibilities

• Running workflows as an administrator

• Workflow configuration settings

• Information disclosure in task and workflow history lists

• Spoofing and tampering attacks in the task and workflow history lists

• User-Impersonation Step type for declarative workflows

List manager, administrator, and developer roles and responsibilities

The following are some common workflow actions and the related responsibilities, which explain the role of administrators and developers in running workflows.

Workflow developers

Develop workflow schedule and template   Workflow developers are responsible for coding the assembly that contains the business logic that will run on a SharePoint item. This assembly is called a workflow schedule. They are also responsible for packaging the workflow forms and assembly into a workflow feature, or into a workflow template.

Site administrators

Manage Central Administration workflow settings   Site administrators can control general workflow settings, such as task alert results and external participant settings on the SharePoint Central Administration Web site.

Deploy Workflow features   Site administrators can install workflow features on a site collection to make them available for association.

List administrators (anyone with Manage List or Web Designer permissions)

Add workflows   List administrators must associate (add) a workflow template to a list or content type, according to the business needs of the list or content type. This association makes the workflow template available to end users, who can then select default values and settings.

Remove workflows   List administrators can remove workflow associations from a list or content type, or prevent new instances from running.

Terminate a workflow   If a workflow instance fails, list administrators can stop a running workflow instance, such as when a workflow instance produces an error or does not start, by using the Terminate this workflow link on the Workflow Status page. This action is reserved for administrators.

Running workflows as an administrator

The most important security concept to be aware of is that workflows run as part of the system account in SharePoint Foundation 2010, through the identity application pool settings on the server computer and domain. This means that within SharePoint Foundation 2010, workflows have administrator permissions. On the server, workflows have the same permissions as the application pool, which frequently has administrator permissions. These permissions enable workflows to perform actions that ordinary users cannot perform, such as routing a document to a specific location or records center, or adding a user account to the system.

This setting, that workflows have administrator permissions, cannot be changed. It is up to the workflow schedule (that is, the workflow code) to detect user actions and, based on those actions, continue or roll back changes, or impersonate a user in order to mimic that user’s permissions.

When they deploy workflows, administrators must understand the actions that the workflow will perform so that they can assess possible risks associated with elevation of permission in a workflow and help the workflow developer reduce any security concerns.

Workflow configuration settings

SharePoint Foundation 2010 has some configuration settings that administrators have to set according to their security needs.

Required permissions to start a workflow

In addition to preventing the elevation of permissions in the code, list administrators can restrict the permission level that is required to start a workflow during the association process. Administrators can select either of two permission levels to start a specific workflow association: Edit Item or Manage List.

The default setting for associating a workflow is to allow users with Edit Item permissions to manually start a workflow. This means that any authenticated SharePoint Foundation 2010 user on the list who has Edit Item permissions can start an instance of this workflow association. If during workflow creation the administrator selects the option to require that the user have Manage Lists permissions in order to start the workflow, only list administrators can start an instance of this association.

Because workflows are designed to be used by standard contributors, most workflows do not require the restriction to Manage Lists permissions. However, administrators can use this setting for workflows such as a document disposal workflow, where the administrator wants only certain people to execute the disposal actions.

Central Administration settings

The following settings can be found on the Central Administration page by clicking Application Management and, in the Web Applications section, clicking Manage web applications. On the Web applications page, select the Web application that you want to configure, and in the Manage group of the ribbon click General Settings, and then select Workflow. The Workflow Settings page opens, and the following settings are displayed:

• User-Defined Workflows

• Workflow Task Notifications

Enable user-defined workflows

By default, user-defined workflows are enabled for all sites on the Web application, as shown in the User-Defined Workflows section of the Workflow Settings page. When this option is selected, users can define workflows in a workflow editor such as the SharePoint Designer 2010 workflow editor. Users who define these workflows must have Manage List permissions on the site to which they are deploying the workflow.

Task notification for users without site access

On the Workflow Settings page, in the Workflow Task Notifications section, you can set options for sending notifications about pending workflow tasks to users who do not have access to the site.

-
Internal users

In SharePoint Foundation 2010 it is possible to resolve the names of internal users in the directory service who are not members of the site or who do not have access to that task. In this case, an administrator can select the **Alert internal users who do not have site access when they are assigned a workflow task** option in the **Workflow Task Notifications** section to set whether such users receive a task notification by e-mail. This option means that users are alerted when they are assigned a workflow task. This option is enabled by default, and the e-mail message that users receive contains a link that they can click to request access to the site (administrators must still grant access). This e-mail message might also contain information about the document. This information can include the title of the document and instructions from the workflow owner. If there are information disclosure concerns associated with internal users who are not members of the site, administrators might want to disable the **Alert internal users who do not have site access when they are assigned a workflow task** setting.

• External users

  External users who are not in the directory service but who are assigned a well-formed SMTP e-mail address can still be assigned workflow tasks. Because external users will find it difficult to access the document, SharePoint Foundation 2010 includes a setting, Allow external users to participate in workflow by sending them a copy of the document, which makes it possible to send external users a task notification by e-mail with the document attached. When this option is enabled, the task is assigned to the workflow owner, and the external user can complete the task by sending e-mail to the owner.

  By default, the option Allow external users to participate in workflow by sending them a copy of the document is disabled. But this setting can be useful in situations that require external participation, such as approval of business documents that involve external customers. Administrators who enable this setting (select Yes) must verify that the workflow schedule supports the external participant setting. For example, when a task is created for an external user, the custom workflow must specify the external e-mail address in the OnBehalfEmail property in the SPWorkflowTaskProperties object that was used to initialize the task). Several built-in workflows in SharePoint Foundation 2010 support this setting.

  Custom workflow developers who want to enable this functionality must work with administrators to determine whether there are information disclosure risks in attaching the actual document to an external e-mail message. Administrators must evaluate the benefits and risks when enabling this setting.

Information disclosure in task and workflow history lists

Because tasks and history list items can contain data about users and the actions they perform on documents, the items might disclose confidential information. For example, a promotion Approval workflow might collect feedback on its tasks that an organization wants only the workflow owner and each participant in the task to see.

Task and history lists are typical lists in a site. By default, therefore, all readers can view tasks and history items. Administrators and developers must determine the information that cannot be disclosed and decide whether to help secure task and history items that are created by the workflow.

Securing these items can be done in several ways. For example, administrators can set list-level permissions. If disclosure is to be private — that is, not publicly available but available to a specific group of people — administrators can create a new task or history list and set permissions for the list that are targeted to that group. If administrators do not want anyone to see history events on a workflow status page, they can remove view permissions to the workflow history list from which a status page pulls its information. Users who do not have permissions to view the history list itself, or any item on the list, will receive an Access Denied error when they open any status page that pulls data from that history list.

If finer restrictions are required, workflow developers can set per-item permissions when they create tasks or history items. The CreateTask activity has a SpecialPermissions property that gives only specified permissions to access the newly created task. The LogToHistoryList activity does not have such a property, so to set per-item permissions on history list items, administrators must use the object model (OM) in SharePoint Foundation 2010. Per-item permissions can affect performance negatively and should not be used unless they are necessary.

Tasks and history items do not have to be handled in the same manner. Administrators can mix and match list permissions and item-level permissions.

Spoofing and tampering attacks in the task and workflow history lists

Any contributor can modify tasks or history items if there are no restrictions on those lists. This means that malicious users can modify task descriptions to give participants incorrect instructions or to order participants to click malicious links. To change the perceived results of a process, malicious users also can add false or inaccurate history events or can modify history events to make them false or inaccurate.

As detailed earlier, task and history lists are normal lists in a site. By default, there are no permission restrictions on either task lists or history lists. To avoid spoofing and tampering attacks, administrators must determine the vulnerabilities that exist and either restrict access to columns in a list (for example, make vulnerable columns such as task descriptions read-only so that only the workflow can set them on item creation), set special permissions on the list, or set item-level permissions on the items in a list.

Security issues in the workflow history list

A key benefit of workflows is the ability to track process information to provide visibility into a process. The workflow history list is a repository for this information, where a workflow status page can search for data related to a workflow instance and can make this information available to users. Users can see all items to which they have access in the history list.

However, because the workflow history list tracks information, users might assume that it can be used as an audit trail for events. This is not the case: Workflow history is not a security feature. History lists are standard SharePoint lists that are used for storing events that are visible to any user and that have no special permissions associated with them. By default, users can modify and add events if they have edit and add permissions on the site. To audit events, use the SharePoint’s Audit Log feature. Only administrators can access this log and the log does not require additional work to protect it from tampering attacks.

To better protect the history list, administrators can restrict edit and add permissions to the list, so that only system account administrators (for example, workflow administrators) and list administrators can add items. List administrators must have add permissions to log "Terminate this workflow" events. If edit and add permissions are restricted on the history list, users still must be granted view permissions in order to see status information.

User-Impersonation Step type for declarative workflows

The User-Impersonation Step type can be used to run sections of declarative workflows by the person who authored the workflow rather than by the workflow’s initiator. Declarative means a model that you use to create the workflow and set the parameters for the workflow without writing any code.

In SharePoint Foundation 2010, declarative workflows always run in the user context of the workflow initiator unless an impersonation step is encountered. If an impersonation step is encountered, the declarative workflow is run in the context of the workflow associator. The default workflow tasks respect SharePoint permissions by impersonating the user who started a workflow when the workflow is run. This arrangement keeps things fairly safe in SharePoint Foundation 2010, but blocks many scenarios in which a workflow designer with high permission levels wants to author a powerful workflow that can be completed successfully by users who have lower permission levels.

Through a safe and scoped form of privilege elevation, site actions can be automated through workflow. This reduces the burden on a SharePoint site administrator. Automation of a high-security process is useful in publishing and approval scenarios in which existing actions are enabled to impersonate someone other than the workflow’s initiator.

The following are sample scenarios that demonstrate the User-Impersonation Step type:

• Publish to a secure list

  Jackie has locked down the Pages document library for the public face of her SharePoint site. She has set up an Approval workflow that, by using Microsoft SharePoint Designer 2010, submits content from site contributors for approval. Jackie puts her workflow actions in an impersonation step so that the workflow actions will always impersonate her, a site administrator, as the author of the workflow.

  When Connie (a contributor) posts a content draft to the Pages library of the site, and tries to publish her article, that action causes Jackie’s Approval workflow to start so that the post can be reviewed and approved. Tasks are sent out to the approvers in the workflow on behalf of Connie. Upon review and approval by the approvers, the system sets the moderation status of the post to “Approved”, even though Connie does not have permission to approve pages.

• Granting permissions to users

  Joanne has set up a workflow in SharePoint Designer 2010 that uses a user-impersonation action “Add User to Group” to grant Design permissions to her site. Because the workflow uses an impersonation scope, the action of adding a user to the group will always be performed on Joanne’s behalf.

  The rest of the workflow lets contributors visit the site and complete a form to log their access request to a list.

  For example, a separate user, Olivier, receives a task when Connie, a user, logs a request, and when he approves the task, Connie is added to the Designer group for the site even though neither Olivier nor Connie has Manage Lists permissions on Joanne’s site.

• Templates and taking ownership

  William created several workflows in SharePoint Designer 2010 and saved them as templates for reuse across the company, but he soon leaves the company. His account is removed, his administrator status is revoked, and now the SharePoint Designer 2010 workflows that William created fail to complete due to the loss of William’s permissions.

  A parent SharePoint site administrator, John, can intervene for each workflow, without having to re-create the workflows in SharePoint Designer 2010. John takes ownership of the administrative symptoms in each broken template. After doing this, secure publishing and access granting now occur under John’s name instead of William’s — and nothing else has changed.

The following are workflow actions that can be impersonated:

• Set Content Approval Status (as Owner)

• Create List Item (as Owner)

• Update List Item (as Owner)

• Delete List Item (as Owner)

• Add/Remove/Set/Inherit List Item Permissions (as Owner)

As a SharePoint administrator, you must consider the possible security effects of incorporating impersonation into workflows on the SharePoint site. This applies to new actions but also to existing actions such as updating list items.

For example, consider a model in which user-impersonation actions in the workflow could still run as the initiator. If a user has administrator permissions only over a site in the site collection, that user could maliciously create a workflow to gain rights to the parent Web of the site. All that the malicious user would have to do is to persuade the administrator to upload a file to a document library on the malicious user’s site to begin the workflow’s attack and compromise the whole parent Web of the site.

This risk prompted development of the restriction “user-impersonation actions always impersonate their associator” in SharePoint Designer 2010. The associator is the person who associates a workflow to a particular list or Web. In SharePoint Foundation 2010 declarative workflows, the associator is the same person as the workflow author; that is, the user who builds the workflow in SharePoint Designer 2010. However, the associator can also be anyone who associates a declarative workflow template. The concern now is that the author/associator is forced to accept responsibility for anything that occurs because of a User-Impersonation Step type, because the author/associator’s credentials are being used in the elevation. This requires that the authors/associators understand the workflows they design or associate. Therefore, during workflow creation, SharePoint Designer 2010 provides a cautionary message on the workflow creation page to the author/associator about the User-Impersonation Step type.