As we support our customers who implement PDF forms in various scenarios, we were asked several times about a common SharePoint scenario: the need to restrict user access to certain columns of metadata. This article focuses on one of the possible solutions we recommend to our customers.

SharePoint provides access control on the document or list item level. Access policies can be scoped at higher level as well: the folder, list or library and site levels. Additional security policies are configured at the site collection level (Site Collection Administrators membership and permission levels) and at the Web application level (User Access Policy). However, once a user has access to an item or document, it is not possible to restrict their access at a field (column) level. The permission the user has to the item — view, edit, delete, add — is the permission the user has to entire set of columns in the list item.

Entire conversation about column security is related to SharePoint out-of-the-box functionality. SharePoint 2003, 2007, 2010, and 2013 do not have column level security. This is per design and Microsoft is very insistent not to change this approach. Main argument is that security on such granular level will negatively affect performance of entire SharePoint infrastructure.

Nevertheless, there are design patterns available that implement column level security using existing SharePoint functionality. One of such models involves leveraging the “related lists” feature of SharePoint. It allows to “project” a field from a child list into the parent list. For example, an “invoice” list, in which user selects a vendor, can display address and telephone information from the vendor list. Our most common use is: connected web parts.

Imagine this scenario: User wants to track “Salary Increase” requests, but needs social security numbers, requested salary, and other important private data to be available only to the Human Resources department. Instead of putting all the data in a single list or document library and then having to try to “hide” columns, put the data in two separate lists, linked by a common field (e.g. Employee ID).

Browsing public and private parts

In views, display both lists in two separate web parts. Visualize a web part on the left where user selects a “Salary Increase” request and sees their publicly visible properties. The web part on the right shows the data from the “{Secured}” list, which contains more sensitive information. The web part on the left is connected to the web part below, based on the Employee ID field. When a form is selected on left, the view filters on the right to show only the selected employee’s sensitive information.

Now here’s the cool part. If user is not in the HR department, and therefore doesn’t have access to the “{Sensitive List}” list, she simply won’t see anything in the web part.

By separating data into lists based on common security requirements, then “stitching together” information in views and forms from the related lists, SharePoint can continue to enforce security at the list level, but the effect is that specific metadata about a single item (Salary Increase Request form) is secured.

Here are some of screenshots to support the above scenario:

  • User A fills in PDF form “Salary Increase Request”. There are 2 fields with private data (SSN, and Requested Salary):  Salary Increase Request
  • Pubic properties and PDF form is saved in “HR Request” document library: Public properties
  • Private properties are saved in “HR Request Secured” list:Private properties
  • User A can see both public and private information using connected webparts: Browsing public and private parts
  • User B does not have permissions to “HR Request Secured” list, so he does not see private properties: Browsing public part only
  • User B also does not see PDF fields if he opens actual form:Public PDF fields only

To implement the described scenario, we have used the following:

  1. Document Library “HR Requests” to save PDF form and public properties.
  2. Custom list “HR Request Secured” to save sensitive information for each PDF form.
  3. Custom page to display both public and private information. There are 2 webparts, linked by employee ID.
  4. PDF form save and display logic was customized:
    • Separately save private data to “HRRequestSecured” list
    • Add logic to hide PDF fields with sensitive information if user is not part of HR department.

This approach leverages SharePoint out-of-the-box features and customization of PDF form to capture user public and private information. There are couple of minor yet inevitable disadvantages with this approach:

  • You need to customize logic to save PDF form data. Default method to save to document library has to be extended to save private data to custom SharePoint list.
  • You need to define logic in PDF form to determine when to hide sensitive PDF fields.
  • You need to support 2 lists: document library to support public properties and PDF form; and second list to support private data storage
  • Connected webparts require a record to be selected first, before private data can be displayed. If you want to see all public and private records in one view, you will need to use “EmployeeID” as connected column.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.