Archive for January, 2015


​There are three types authorization policies in SharePoint 2013. This post explains what each of this means and where exactly these are used.

AppAuthPolicies

 

User-Only:

This was the policy which was there in 2010 too. Whenever your code gets executed, only the user permissions are considered. If the user have the rights to do what the code have to do, it executes fine. There is no other authorization required.

 

User + App:

As you start coding your SharePoint apps, you will come across the terms like App Manifest, App permissions etc.,  where in you mention certain permissions your app needs to execute the code it contains. Some of such permissions levels are (Read, Manage etc,). In this case, when your code gets executed, the app should have the required permissions & also the user whose context the app is getting executed should have the same level of permissions.

For example, in case your app is trying to update an item in a list in your host web, your app may have Write permissions  but if your user is having only Read permissions your code will not execute & vice-versa. So both your app and the user should have Write permissions for the app to work.

To put it simply both your user context and app context are taken in to consideration here.

 

App-Only:

If at all a timer job can be made possible for SharePoint online, then it’s using this authorization method.

This method allows you to execute code even if the current is not having the required permissions. We will not be able to elevate/provide every user the required permissions. But we need to perform an action that the user is not entitled to. People always consider this as a replacement for RunWithElevatedPrivileges in farm solutions. But it’s not. This is not same as RunWithElevatedPrivileges. RunWithElevatedPrivileges still takes the current user context in to consideration. But in this case we ask the app to totally ignore the user context.  This is done by adding the property AllowAppOnlyPolicy=”true” to your app manifest file. Below will be the permissions you will see in the manifest file.

<AppPermissionRequests AllowAppOnlyPolicy=”true”>

<AppPermissionRequest Scope=”http://sharepoint/content/tenant&#8221; Right=”Manage” />

</AppPermissionRequests>

In general, a current user is required to be present for a call to be made. In the case of app-only policy, SharePoint creates a SHAREPOINT\APP, similar to the existing SHAREPOINT\SYSTEM user. All app-only requests are made by SHAREPOINT\APP. There is no way to authenticate as SHAREPOINT\APP through user-based authentication.

Since app-only calls effectively does what a user is not meant to do , you should be conservative in creating apps that ask for permission to make them. Calls should use the app-only policy only if:

  • The app needs to elevate its permissions above the user for a specific call; for example, to approve an document under conditions evaluated by the app.
  • The app is not acting on behalf of any user; for example, an app that performs nightly maintenance tasks on a SharePoint document library.