SharePoint 2013 - Implemented RunWithElevatedPrivileges With Apps (S2S)

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 AppOnlyPermssion comes 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 the TokenHelper 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 using RunWithElevatedPreviledges in the Server Object Model.

References:

"SharePoint 2013 App Only Policy Made Easy"