Rapid “Data Collection” Solutions – Part 4: designing and implementing a security model

I refer to the business problem already described in the post “Rapid “Data Collection” Solutions – Part 1: defining the business problem”. In this series of posts, I am considering the options available for building a quick and – possibly – zero-code solution based on a SharePoint web environment.

In my previous post “Rapid “Data Collection” Solutions – Part 2: designing and implementing a data model” I have considered the problem of “preparing the storage” for the data that need to be collected; in that post I have also described the possibility to implement some kind of “data-completion workflows”, helpful especially when it is desired to automate the filling of “redundant columns”. In the sequent post “Rapid “Data Collection” Solutions – Part 3: designing and implementing the business process” I have considered some aspects of the “business process workflows” (or “human workflows”) implementation.

In this post I will describe the most important concerns that must be addressed when planning and implementing the security model for such a kind of data collection solution.

I will not explain the SharePoint security model: I assume that this is already well known to the reader; if it is not, I suggest starting with the reading of these articles: “Plan site permissions (SharePoint Foundation 2010)” “Plan site permissions (SharePoint Server 2010)” (both articles are about SharePoint 2010 but the same concepts are valid for WSS 3.0 and MOSS 2007). I summarize what is written in these articles with the following sentence (that also gives me the opportunity to set the “security vocabulary” used in the rest of this post):

In SharePoint, the authorization mechanism consists in assigning, on a securable object(web, list, item or folder), one or more permissions levels (set of base permissions) to a security principal (user or group); the assignment can be explicit or inherited from the permissions set on the above securable objects in the site collection hierarchy.

Another important rule that need to be considered here is the following one:

A declarative workflow designed and deployed through SharePoint Designer is always executed in the security context of the user that started the workflow.

Now, it is time to summarize what are the elements that compose the data collection solution described in this and in my previous posts. When considering the involved “securable objects”, it is important to notice that the entire solution is confined into a single SharePoint web; in detail, we have considered the following securable objects:

· The “main list” containing the result of the data collection initiative; it is worth to highlight that this is the list where the optional “data-completion workflows” and the “business process workflows” are associated.

· A set of “related lookup lists”, allowing the representation of an optional data model around the collected data

· A “Tasks list”, containing the tasks assigned to the users involved by the “business process workflow”; with SPD 2007, all the workflows deployed in a web must use the same tasks list; with SPD 2010 you have the option to assign a specific list to each workflow.

· A hidden “History list” containing the messages logged by the implemented workflows (the messages shown on the workflow’s status page); with SPD 2007, all the workflows deployed in a web must use the same history list; with SPD 2010 you have the option to assign a specific list to each workflow.

· Optionally a “custom history list”, containing the evolution of the important values in the items subjected to the “business process workflows”.

· A set of “custom forms” – stored into an hidden document library – automatically created (as “.xsn” files in SharePoint 2010 and as “.aspx” files in SharePoint 2007) during the deployment of the “business process workflow” (why do I explicitly mention these forms? I will explain shortly why they must be considered when planning and implementing the security model…)

What about the “roles” that we have considered in this series of posts? They were not explicitly mentioned until now; it is time to define them. Trying to be generic, it is possible to say that:

· there are individuals that must be able to prepare and manage the data stored into the “model” designed around the data to be collected;

· there are individuals that must be involved into the data collection process as contributors only for the part of data that they own;

· there are individuals that need a read-only access to the collected data.

Certainly, in this way I have not described all the possible situations in details: there are scenarios, for example, where a certain group of individuals must be able to manage only a specific set of the data model designed around the data to be collected. A more detailed description of all the possible security requirements is not practically possible in this post; now I need to consider a more generic and simplified vision, in order to define at least a “base solution” for the security model.

Trying to map these “base security needs” with the SharePoint security model principles and with the declarative workflow security rule mentioned above, we can design the solution described into the following table in terms of permission levels that must be assigned to the involved security principals on the involved securable objects:

In the previous table I have not explicitly considered the standard hidden “history list” where the workflows log their messages, because the permission assignments on this list are managed directly by SharePoint.

The “Read” permission level assignment to the “custom task forms” is done automatically during the workflow deployment; there are situations where you may need to update these assignments by adding new security principals; for more information on this subject I suggest reading this post: “Dynamic tasks assignment and access denied errors in declarative workflows [SPD 2007 only]”.

It is important to notice that the described solution for the security model allows to implement a “separation of contexts”: the users involved by the business process workflow as contributors in the data collection process require the “contribute” permission level on the “tasks list” but do not need the “contribute” permission level on the “main list”, neither when the information provided by these users are copied back in this list (accordingly to the approach that I have described in “Rapid “Data Collection” Solutions – Part 3: designing and implementing the business process”). This is true because this copy is done by the workflow, which is always executed in the security context of the user that started it (the completion of a task by an assignee does not change this security context!).

For the same reason, it is important to notice that the users allowed to start the “business process workflow” require the contribute permission into the (optional) “custom history list” and into the “tasks list”.

The “business process workflow” is normally configured to be started automatically by the creation of a new item in the “main list”; for this reason, in the previous table, I have depicted the “Contribute” permission level as the only permission assignment required on the “main list” for the users allowed to start this workflow. If the startup of this workflow must instead be done as a manual operation, it is possible to require the possession of the “Manage list” base permissions (which is not part of the standard “Contribute” permission level). This option allows to further implement a “separation of contexts”: the contributors of the main list prepare the items where specific enabled users can start the “business process workflow”.

Please note that, in this post, I will not consider the following SharePoint functionalities related to the list content security management:

· the list item “approval mechanism”;

· the “item-level security” (I am referring to the options available in the advanced list settings);

In the rest of this post I will consider some specific but quite common security needs:

· How to avoid the deletion of the items, especially from the “main list” and/or from the “custom history list”?

· How to protect the value of specific fields for the items in the “main list”?

· How to protect the “tasks” created by the workflow, in order to allow only their assignee to update and complete them?

Avoiding the deletion of items

A common need consists in avoiding the deletion of the items, especially from the “main list” and/or from the “custom history list”. This requirement can be easily enforced by simply replacing the base “Contribute” permission level with a custom permission level, created as copy of the “Contribute” permission level but deprived of the “Delete items” and “Delete versions” base permissions. This approach, associated with the enablement of the standard versioning mechanism on both lists, allows the complete control over the modifications that happen on both these lists. If you need to have this control while maintaining the right – for your users – to delete the items, you have to set up the SharePoint auditing mechanism.

Protecting specific fields

Another common need consists in “protecting” specific fields, especially in the “main list”; for example, you may not want the contributors on the “main list” to be allowed to change the content of specific list item fields whose value should be automatically managed by the workflow; these fields may contain:

· the status of the item, according to the process implemented by the business process workflow;

· the information provided by the involved users in their completed tasks and copied back on the current list item by the same business process workflow.

We need to point out that this requirement cannot be completely satisfied, because the SharePoint security model does not allow the protection of the fields (the fields are not securable objects). In spite of this limitation, you can implement a strategy allowing a “good protection” of the “sensitive fields”. This strategy may be realized by imposing the following settings on the “main list”:

· hide these fields from the new/edit item forms (in order to do this, you have to temporarily enable the content types association on the advanced settings of the list; the hide option is then available on the specific content type fields settings);

· hide these fields from the views associated to the list;

· add a “shadow field” for each of the fields previously hidden; this shadow field is simply a field of type “calculated value”, showing the content of its related field (for example, an “Item Status – View Only” shadow field should be created with the following formula for its value: “=[Item Status]”, where “Item Status” is the name of the protected sensitive field)

· add these shadow fields to the views associated to the list;

· enable the versioning on the list, in order to have a log of the modifications occurred to each item;

· replace the base “Contribute” permission level – associated to the users allowed to start the business process workflow – with a custom permission level, created as copy of the “Contribute” permission level but deprived of the “Delete items”, “Delete versions” and “Manage Personal Views” base permissions.

When the above settings are enforced, the users will not be able to modify the content of the protected fields by using the standard SharePoint web pages (the list views pages, the list view web parts and the list item forms).

I am suggesting the use of the “shadow fields” because, when you only hide the protected fields in the new/edit list item forms, the users are still enabled to edit their values in any list view showing them; in order to do so, they can simply switch the view in “Datasheet mode” (if the view is not already a “Datasheet View”). By adding the “shadow fields” to the configured list views (instead of directly the protected fields), your users will still be able to see the value of the protected fields but they will not be able to update them.

Please note that this solution requires that your contributors on the “main list” will not be enabled to create personal views (they must be deprived of the “Manage Personal Views” base permissions); otherwise they could create a personal view including the protected fields, making them available for modifications.

It is important to point out that, with the proposed solution, the contributors of the “main list” are still able to modify the value of these protected fields when they access them outside the standard SharePoint web pages. For example, they can modify these fields by editing the list with Access 2007/2010 (using the linked table feature of SharePoint/Access). Fortunately, in the described configuration, the versioning mechanism (to be enabled on the “main list”) and the missing “Delete items” and “Delete versions” base permission assignment allow to find such undesired “behaviors” of your users; in this situations, a proper “communication strategy” addressed to your users is the only way to fill the final gap towards a complete protection of the sensitive fields…

Protecting the tasks items

A third common need consists in protecting the single task items by allowing them to be seen/modified only by their assignees. By default, the items created in the “Tasks list” inherits the security settings of the list; for this reason, all the contributors on this list are allowed to edit /complete/ delete any existing task, no matter to whom the specific task is assigned to.

Unfortunately, it is not possible to obtain this restriction without coding. If the task level security is a requirement, a valuable option could consists in creating, with Visual Studio, a custom action allowing the creation of a task with the “Contribute” permission level automatically granted to its specific assignee (user or group) and, optionally, with the “Read” permission level granted to other users or groups specified somehow.

Please note that the use of the simple “Set Permissions on Item” custom activity available in the “Useful Sharepoint Designer Custom Workflow Activities” (from CodePlex) is not valid: you cannot create a task using the standard “tasks activities” and then set the permissions on the task with that specific custom activity because each of the “tasks activities” cause the stop of the workflow just after the task creation, until the task is completed.

An intermediate and limited solution – allowing a partial protection but not requiring the development and deployment of custom code – consists in limiting, on the “Tasks” list, the use of the “My Tasks” view to all the possible tasks assignees. This can be easily done by deleting the other views and by removing the “Manage Personal Views” base permissions from the permission level assigned to this set of users on this list. This approach has two important leaks:

· firstly, the users can still access and modify the other list items not shown in the prepared views (the tasks not assigned to them) just by accessing them with one of the many tools that allow this functionality outside the SharePoint web pages. For example, they can modify these tasks by editing the list with Access 2007/2010 (using the linked table feature of SharePoint/Access);

· secondly, the views can only filter the tasks directly assigned to the current user (the standard “My Tasks” view, for example, uses the filter “”Assigned To” “is equal to” “[Me]”); these views cannot filter the tasks assigned to a group (SharePoint group or Active Directory group or generic identity provider role) to whom the current user belongs.

It is worth to notice that the standard “Approval” workflow template available in MOSS 2007 and SharePoint Server 2010 (but not in WSS 3.0/SharePoint Foundation) enforces the protection of the tasks (if a non-assignee tries to update a task, the operation is aborted with the generic error message “Task update was not accepted”). This behavior is not obtained with a standard permission level grant but with other custom mechanisms. The same behavior is not present in other standard workflow templates; for example, it is not present in the (similar) “Collect Feedback” workflow template available in MOSS 2007/SP 2010.