Sharepoint 2010 : Creating and Managing Workflows - Planning for Workflow Deployment

1. Identify Roles Involved

As an administrator, you should be aware of various different roles involved in creating, deploying, and running workflows. In the following sections, you explore these roles and their associated responsibilities. Understanding these roles and how they impact workflow development will help you plan and mitigate any issues that can occur during the development life cycle or workflow execution.

1.1. Architects

Architects are responsible for identifying the appropriate business processes to be developed as workflows, based on the value created by the workflow to the organization. They are also responsible for selecting the workflow development tools, workflow development language, and the best practices that align with the enterprise architecture. Architects provide oversight of the various systems involved and how they will be integrated to automate the business processes of the organization. Architects ensure smooth transition of business strategies to vision scope to logical architecture to physical architecture to operational systems.

1.2. Workflow Developers

Developers are responsible for developing workflow templates, forms, and the assembly that contains the business logic used during workflow execution. This assembly is called a workflow schedule and is created using Visual Studio 2010. Developers are also responsible for packaging the workflow forms and assembly into a workflow feature and then into a solution package, which will be deployed to a SharePoint farm. Workflow developers are responsible for any issues that are encountered while executing custom workflows deployed in the SharePoint environment.

1.3. Information Workers

Information workers are responsible for modeling workflows using SharePoint Designer 2010. Information workers use the administrator-approved list of workflow activities to model their workflows and associate the workflows to a list, library, or a site. They can also create reusable workflows for a site collection. Information workers can create workflow steps that execute with the same permission as they have at the site level.

1.4. Farm Administrators

Farm administrators are typically part of the IT operations team. They are responsible for the Central Administration settings that will impact workflow development, deployment, and execution. Accordingly, they have the following responsibilities.

• Manage Central Administration workflow settings Farm administrators can control general workflow settings, such as task alert results and external participant settings, within the SharePoint Central Administration website.

• Deploy Workflow Solution Package and features Farm administrators can install solutions that contain workflow features and deploy workflow features to Web applications. Optionally, they also can activate those features on a site collection, making them available for association.

1.5. Site Collection Administrators

Site collection administrators are responsible for controlling the workflows that can be used within their sites. All custom and predefined workflows are deployed as features. By deactivating these features, the site collection administrator can prevent these workflows from being used within their site collection.

1.6. List Administrators

List administrators are groups or individuals with Manage List or Web Designer permissions. They can add specific workflows to a list and control their execution at the list level. Their responsibilities include

• Adding a workflow List administrators 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.

• Removing a workflow List administrators can remove a workflow association from a list or content type, or they can prevent new instances from running.

• Terminating a workflow If a workflow instance fails with an error or does not start, the list administrators can stop a running workflow instance by using the Terminate This Workflow link on the Workflow Status page. The Workflow Status page is visible to all participants of a workflow, but the link required to terminate a workflow link is reserved for list administrators.

1.7. Site Users

Site users are primarily participants of the workflows and are responsible for completing various tasks assigned to them by the workflow instance. They can also delegate the workflow tasks to other participants if the workflow provides such a feature.

2. Security Considerations

As an administrator, the security of your environment is one of your primary responsibilities. Implementing workflows in your SharePoint environment requires proper planning, and you should be aware of potential issues that can be caused by the workflows.

2.1. Workflows Run as Administrators

The most important security concept to be aware of is that workflows run as part of the system account in SharePoint 2010, through the identity provided within the application pool settings on the server computer. This means that within SharePoint 2010, workflows have administrative 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 (for example, a records center) or adding a user account to the system.

Note:

SECURITY ALERT You cannot restrict the administrative privileges given to workflows. It is up to the workflow code to detect user actions, and based on those actions, continue or roll back changes, or impersonate a user to mimic that user’s permissions.

As an administrator of your SharePoint environment, you must understand the actions that the workflow will perform so that you can assess the possible risks associated with the elevation of permissions and help the developer mitigate any security concerns.

2.2. Impersonation in Declarative Workflows

Declarative workflows created using SharePoint Designer 2010 allow the information worker to configure the workflow steps (part of the workflow) to run using their permission. In SharePoint 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 author. This feature is very useful for workflow authors, because it allows for the creation of workflows that perform activities that cannot be performed by a participant but are necessary for the workflow to complete.

Through a safe and scoped form of privilege elevation, site actions can be automated through workflow. This reduces the burden on the SharePoint site administrator. Automation of a high-security process using workflows is useful in publishing and approval scenarios in which specific actions are enabled to impersonate someone other than the workflow’s initiator. The following are some of the scenarios where an impersonation step can be used.

• Publish to a secure list A workflow author can create a workflow that would allow a contributor to publish the content he or she is authoring to a secure library to which the contributor does not have access.

• Granting permissions to users As a site administrator, you would like to allow business users to grant permissions to lists on your site. So you want to create a workflow in which a request is raised by a user who seeks access to a secured list. An approver user in the site can approve the request and the workflow will grant the requester access to the site. The approver user need not have list administration privileges to perform this action.

The following is the list of activities that can impersonate the workflow author:

• 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)

Knowing that the information worker can create impersonation steps will help you assess any security threats that could be posed by such workflows.

2.3. Permissions to Start Workflow

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 allows users with Edit Item permissions to start a workflow manually. This means that any authenticated SharePoint 2010 user on the list who has Edit Item permissions can start an instance of the workflow association. If the administrator selects the option to require a user to have Manage Lists permissions to start the when the workflow is created, 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 List permissions. However, administrators can use this setting for workflows such as a document disposal workflow and other cases in which the administrator wants only certain people to execute the disposal actions.

Note:

SECURITY ALERT By default, user-defined workflows are enabled for all sites on the Web application. When user-defined workflows are enabled, users can define workflows in a workflow editor such as the SharePoint Designer 2010. Users who define these workflows must have Manage List permissions on the site to which they are deploying the workflow. The information worker can create workflows with the impersonation step. So, if you think that these declarative workflows are a threat to your site, you can prevent user-defined workflows on your Web applications until the threat is identified and removed.

3. Information Disclosure

Workflows that execute on your site can disclose information through tasks allocated to the users, through workflow tasks, or through task notifications to users who would not otherwise have access to this information. Some of these information disclosures can be prevented by configuration settings.

3.1. Task Notifications to Users Without Access

When a user starts a workflow, he or she can assign people to participate in the workflow. But in some cases, some of the participants may not have access to the list or site where the workflow is started. As the workflow executes, tasks are created for these participants and task notifications are sent so that they can act on the tasks. The task notifications can contain a link to the task, document, or list item, in addition to any message provided by the workflow imitator, thus leading to information disclosure. Also, these participants could be internal or external users (employees of your partner companies, for example).

SharePoint 2010 allows you to control whether such notifications can be sent and also whether they can be sent to both internal and external users.

3.2. Workflow Tasks and Workflow History

Tasks created as part of workflow execution are created in a standard task list on the site. Anyone with contribute permission to the task list can view all tasks on this list; this means that users might see links to documents to which they do not have access. Apart from tasks, a workflow also leaves a trail of actions performed during workflow execution to a workflow history list. Any user with view permission can see data captured in the workflow history list.

Securing tasks and workflow history items can be done in several ways. One way is for an administrator to set list level permissions. If disclosure should be private—that is, not publicly available but available to a specific group of people—then an administrator 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 the 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.

As an extreme case, an administrator can request that workflow authors set permissions for the tasks or workflow history items so that only users who are participating in the workflow can see these tasks. 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, developers must use the object model (OM) in SharePoint 2010.

Note:

Using item level permissions can impact the performance of your SharePoint site. Use this capability with caution.

3.3. Tampering with Tasks and Workflow History Items

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.

Task and history lists behave as normal lists in a site. By default, there are no restrictions on either task lists or history lists. To avoid spoofing and tampering attacks, administrators must determine the vulnerabilities that exist within their site 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 list items.

Note:

Do not use a workflow history list as an auditing tool for workflows. Plan to use the SharePoint Audit Log capability for auditing workflows and their actions. See the following sidebar titled Workflow History Lists vs. Event Audit Trails for more information.

Real World: Workflow History Lists vs. Event Audit Trails

A key benefit of workflows is the ability to track execution data to provide a view into the progress of the workflow. The workflow history list is a repository for this data, where a workflow status page can search for data related to a workflow instance and 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 of events. This is not the case, because a workflow history list is not a security feature. History lists are standard SharePoint lists that are used for storing events and are visible to any user. These lists have no special permissions associated with them. By default, users can modify and add events if they have Edit and Add permissions within the history list. To audit events, use 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.