If you are a SharePoint developer, the app model in SharePoint 2013 can be hard to get your head around. I’ve noticed that there is a great deal of confusion and misinformation floating around concerning security. The purpose of this post is to help you understand the meaning of the terms "High Trust Apps" and "Low Trust Apps".
To configure a development environment for high trust communication read this article which provides complete documentation for the setup… How to: Create high-trust apps for SharePoint 2013 using the server-to-server protocol (advanced topic).
You might be surprised to learn that you can also create low trust applications for local deployments without any cloud services. To set that up read this article… SharePoint Low-Trust Apps for On-Premises Deployments.
The low trust configuration article contains some excellent background on OAuth and the two flavors of trust directly supported out of the box, how to set it up, and what happens under the covers. However, none of the articles I’ve read have made it clear what the fundamental difference is, so here goes…
What is a High Trust App?
A high trust app uses the server to server protocol between your server and SharePoint. It is high trust because it can assert the identity of any user without knowing the user’s password and SharePoint will trust that it is working on behalf of the user. This does not mean that high trust apps can pretend to be an admin and do everything an admin can do! Every app has a manifest which specifies the permissions available to the app. No matter the user which the app asserts, the app cannot execute any operations above the permission level of the app itself.
This model is extremely useful when the app needs to do something on behalf of the user and it is much better than RunWithElevatedPrivileges which assumes the identity of the System account. If the app asserts a call as Jane Doe that modifies an item, the modified by field will say Jane Doe.
The app is further constrained by the permissions of the user it asserts. If an app has full control, but asserts the identity of a user with only read permissions, any attempt to work above the read permission level will produce an Access Denied exception. This is why the default app code for provider hosted sites looks like this:
The normal case is to act on behalf of the user who accessed the internal site. However, if you need to assert a more privileged identity you can without having to elevate and assume the identity of the app pool account. This is much better than the farm code most people write!
What is a Low Trust App?
A low trust app communicates with the SharePoint server using the app’s identity. It is not allowed or trusted to pretend to be someone else and it has the permissions defined in the app manifest. A low trust app is appropriate for Office 365 and other types of environments where the server that provides the functionality for the app and the server that hosts SharePoint do not share the same directory services or authentication mechanisms. In this case the OAuth trust relationship represents a static identity.
I hope that helps you understand the difference between these two models as well as what you are used to in farm development. If you understand this better than I do and would like to correct me, please comment so I can improve this post!
If you are waiting for me to write some more about provisioning, please be patient for a while longer. I’ve been busy and I want to make sure I test the code completely against the RTM bits before I write any more. I’ve already found a couple of differences.
Author: Doug Ware