Sharing content in SharePoint 2013 is a double-edged sword.
One edge cuts the friction in sharing content with others. There are buttons in many places, making it easy to share. The other edge cuts through the carefully-crafted governance and security of a site. I've spent much of my SharePoint career in the security space and have seen this problem go from massively controlled and complicated to widespread and complicated. :) The goal of this article is to explain a few of the important concepts, to show how the various "Share" buttons in SharePoint 2013 relate to those concepts, and to explain an administrative approach that can help when necessary.
Sharing Concepts
When discussing security of resources we have three items to consider:
- The resource being secured
- The security principals allowed to access the resource (users, groups)
- The level of access granted to the principal for the resource.
In most cases, the principals and level of access are quite clear. In the sharing dialog below, the user fills out the form and selects the principal(s) [Orange] and level [Red]. The resource being shared is also shown [Blue], but how many busy users actually read the title of a dialog?
Figure 1 - Share Dialog in SharePoint 2013
Even more confusing, launching the Share dialog above can be invoked from many places On a SharePoint page.
Figure 2 - Document view page
While I admit the page depicted in Figure 2 is specifically chosen to illustrate the point, keep in mind that each of the Share buttons applies to a different scope.
Scopes and Inheritance
SharePoint implements an inheritance model in regards to security. The SharePoint hierarchy is well documented, but security can only be applied at four levels: Sites, Lists, Folders, and Items. The permissions set at a site will, by default, apply to all the items in the site (including sub-sites). Permissions for a list apply to all folders and items in that list. And so on. When launching the Share dialog, the scope is represented as an object, and the title of that object is shown as the title of the dialog. In Figure 1, the object is a document (list item) titled Current Job Listing. The Share dialog was launched from the page in Figure 2 using the button with the yellow tag number 3. The scope of sharing from yellow tag 1 is the site and the scope of sharing from yellow tag 2 is the list.
In Figure 2, yellow tag 2 applies to the current list. This is evident by the "Library" tab being selected. The "Files" tab also has a share button, which would apply to the currently selected item. It is quite common to confuse these tabs, thus sharing at the wrong scope. If you meant to share a single item, then sharing all items is most likely an issue. (I agree that the share buttons are different, but again, not all users will notice that distinction, particularly when their focus is on completing a task instead of administering SharePoint security.)
Figure 3 - Library and File tabs of the SharePoint ribbon
Administering Sharing in SharePoint
In many sites in SharePoint, the confusion around sharing is not an issue. Publishing sites are often managed by content authors who are trained or experienced in SharePoint. Team sites are designed for sharing, and personal sites have clearly defined folders for sharing. But occasionally I will see a site that has sensitive information and is created solely for the sharing of this information. In this instance, there is a feature of SharePoint that can help to mitigate the risk of oversharing.
SharePoint 2013 includes a feature known as Access Requests. Enabling this feature will allow site collection administrators and members of the Site Owners group to review the sharing request before the permissions for the object are changed.
The Access Request capabilities require the Outbound Email settings to be enabled. For SharePoint Online, outbound email is configured by the service. For on-premises SharePoint farms, the configuration steps are detailed on TechNet: Configure outgoing email for a SharePoint 2013 farm.
With the farm configuration complete, site collection administrators and members of the Site Owners group can enable the Access Request capabilities on a site with unique permissions (i.e. not on a site that inherits from its parent). The Site Permissions page (accessible from Site Settings) has a button in the ribbon, as shown in Figure 4.
Figure 4- Site Permissions page of site with unique permissions
Clicking the button displays the Access Requests dialog. The dialog from SharePoint Online is displayed in Figure 5.
Figure 5- Access Request Settings dialog in SharePoint Online
Access Requests and Sharing Requests
The Access Request Settings capability has that name because its original intent is to allow users to request access to a resource. A typical use case: a user forwards an email with a link to a file. The sender has access to the site, but the recipient does not. When the recipient clicks on the email, the Request access page is displayed. The request then goes through the approval process. Fortunately, this same process can be used when the Share button is used to grant access to a resource.
Figure 6 - Request Access page
In SharePoint Online, to force the sharing of resources to go through the approval process requires that the "Allow members to share the site and individual files and folders" option be unselected, as shown in Figure 5.
Sharing approval walk-through
To illustrate the process, let's walk through the scenario of sharing a document in SharePoint Online. In this scenario, Garth is a member of a team site, and has Edit permission throughout the site. Garth wants to share an image with Denis. Garth uses the Share button on the file preview dialog (Figure 7).
Figure 7- Sharing a document from the preview page
In the Sharing dialog (Figure 8), Garth selects Denis and clicks Share.
Figure 8- Share dialog
If Access Requests is not enabled, at this point Denis would be granted access and he would receive an email with a link to the file. However, with Access Requests enabled, the approval process is used. Garth receives a notification after sharing that the request must be approved. This notification is shown in SharePoint as well as in an email (Figure 9).
Figure 9- Approval required notification in SharePoint and email
As you may have noticed in the Access Request Settings dialog, an email address is specified. This email address receives an email indicating that a sharing request was made (Figure 10).
Figure 10 - Sharing request approval decision required email
In addition to an email, there is a page in Site Settings (Figure 11) that details all the Access Requests. This page includes pending requests as well has a history of past requests.
Figure 11- Access request and invitation link in Site Settings
The administration page (Figure 12) lists pending requests and has buttons to allow quick action.
Figure 12- Access request and invite administration page
The default permission assigned using the Approve button is "Can Edit" which results in assigning the Edit permission level to the user (Figure 13).
NOTE: If you have a policy to grant permissions using groups instead of users, then you cannot use the quick access buttons to implement the permissions change. The details page allows the selection of a group (Figure 14).
Figure 13- Resource permission page showing the effect of Approving request
If the default settings are not appropriate, clicking the context menu (the ellipsis) on a request provides more granular options on the details page (Figure 14).
Figure 14- Detailed settings of access request
On the detail page (Figure 14), the permission level can be changed. The dropdown lists the permissions levels as well as the SharePoint groups in the site. Any comment entered in the Conversation box are displayed to the requester if they visit the site before permissions are granted and are emailed to the requester. (Figure 15).
Figure 15- Access denied page with conversation and email response
At the bottom of the Access Requests and Invitations page is a link to Show History. The history view shows a record of the approval decision and the user who implemented that decision (Figure 16).
Figure 16- Access Requests and Invitations page with history displayed
Finally, notice of approved requests are sent to both the user receiving access and the user making the share request.
Figure 17- Email to Denis that document has been shared
Figure 18- Email to Garth confirm access approved.
Summary
The Access Requests capability of SharePoint is an integral tool in enforcing the governance of sites. Used correctly, it can balance the need to share resources correctly with the ease-of-use that is appreciated by most users. To get the best benefit, the users that are reviewing requests should be well-trained in the security concepts of SharePoint.