SharePoint 2013 – Implemented RunWithElevatedPrivileges With Apps (S2S)

Posted: December 12, 2015 in SharePoint2013

Introduction

In this article we are going to see how to elevate user permission in SharePoint Apps similar to RunWithElevatedPrivilages with Full trust Code.

Elevate User Access with App Only Policy

Scenario

The reason we use RunWithElevatedPrivilages is to execute our code with elevated permission regardless of current login user permission.

By default, SharePoint Apps run in context of user + app which means current user and the app both should have sufficient rights to access SharePoint resources. But in some cases we need our app to access SharePoint resources regardless of current user permission, this is where AppOnlyPermssioncomes into picture. In this article I will let you know how to use it.

Solution

To make an App performing work that the user does not have permission to means we will use the app only policy. To enable the App Only policy in your app, you have to add the “AllowAppOnlyPolicy” attribute to your “AppPermissions” element in the App Manifest:

  1. <AppPermissionRequests AllowAppOnlyPolicy=“true”>
  2. </AppPermissionRequests>

This capability is only available to provider-hosted apps. It is not available to SharePoint-hosted apps. In a SharePoint-hosted app, there is Full trust code and is not limited by permissions – it can do anything it wants.

S2S (High Trust) – App Only Context

An S2S access token by calling the GetS2SAccessTokenWithWindowsIdentity method of theTokenHelper class. Use the TokenHelper::GetS2SAccessTokenWithWindowsIdentity method, passing a null for the WindowsIdentity parameter.

On-premises farm

Let’s see how we can actually utilize the App Only policy to elevate user permissions. I have written the following code in the code behind of the TestPage.aspx of S2S Provider Hosted App.

Code:

  1. Uri _hostWeb = new Uri(Request.QueryString[“SPHostUrl”]);
  2. string appOnlyAccessToken = TokenHelper.GetS2SAccessTokenWithWindowsIdentity(_hostWeb, null);
  3. using(ClientContext clientContext = TokenHelper.GetS2SAccessTokenWithWindowsIdentity(_hostWeb.ToString(), appOnlyAccessToken))
  4. {
  5.     List Testlist = clientContext.Web.Lists.GetByTitle(“TestList”);
  6.     ListItemCreationInformation info = new ListItemCreationInformation();
  7.     Microsoft.SharePoint.Client.ListItem item = Testlist.AddItem(info);
  8.     item[“Title”] = “Created S2SApp”;
  9.     item[“Body”] = “Created from S2S” + DateTime.Now.ToLongTimeString();
  10.     item.Update();
  11.     clientContext.Load(item);
  12.     clientContext.ExecuteQuery();
  13. }

Deploy the app and then log on as a user that only has read permission to the list. Execute the code, and a new item is created even though the user does not have permission to create items in the list. The Created By and Modified By fields in the list will reflect that it was the SHAREPOINT\App account that were used to create the item.

Note:

As you can see, the ClientContext that is opened with the appOnlyAccessToken will run with the identity of the SHAREPOINT\App account. This is a very good practice to remember even when usingRunWithElevatedPreviledges in the Server Object Model.

References:

“SharePoint 2013 App Only Policy Made Easy”

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s