The app model for SharePoint has been around for some time now and the different models for app hosting have been quite well documented. Yet, there is quite a lot of outdated or plain erroneous information on this subject floating around on the internet. This is especially true for provider-hosted apps. For example, even though we've said goodbye to the Azure Auto-hosted model almost a year ago now, you'll still find references to it when looking for app examples. Another common misconception is that Azure or Azure Access Control Services (ACS) are required for provider-hosted apps, while Azure is completely optional in this scenario. In a series of blog posts of which this is the first post, I'll try explain the concept of provider-hosted apps, show you how to install them and help you troubleshoot your installation should something go wrong.
The provider-hosted high trust app model is powerful tool which should be utilized when the situation either demands custom managed code or when a low-trust solution does not suffice. In other words, you need custom development and the SharePoint-hosted model does not meet your requirements.
When to create a provider-hosted app
A provider-hosted app brings two very powerful tools to the table: managed code and high trust. With managed code, the developer is free to use any programming language he or she deems fit for the task. However, the app model does not allow managed code to be installed directly on SharePoint. This seems like a deficit at first, but it is easily resolved by introducing an "app server" and hosting the code there. All we need is a separate website, for example on IIS. On my development environment I suffice by simply adding a separate IIS site on the SharePoint server. This keeps the app code separate from SharePoint without introducing new infrastructure. Obviously, this is not advised for a production scenario.
High trust apps can have their own set of permissions and are, as opposed to low trust apps, not constrained by the permissions of the user. This means that a high trust app can perform actions for a user, which the user him- of herself is not allowed to perform. A tightly controlled form of elevation.
In summary, if you require server-side managed code or if you need some sort of context elevation, a provider-hosted could the correct choice.
How does it work?
A provider-hosted app consists of two parts, the app for SharePoint and a website that contains the actual code, called the AppWeb. Since the AppWeb is not actually part of SharePoint but runs on a separate site or server, the high trust on premises scenario requires that we're able to create a trusted connection between SharePoint and the AppWeb. On SharePoint 2013 authentication and trusts are managed by passing tokens to one another, thereby confirming identity. This is also the main reason why SharePoint 2013 farm should always be hosted on SSL. The tokens can open the door to permissions, so sending these tokens over an unencrypted connection introduces a security risk.
Since the "regular" tokens SharePoint uses will only work with a user context, we need something to create high trust tokens for us. This is where we introduce a trusted security token issuer to your farm. This token issuer uses a matched set of public and private version of a server certificate to establish a secure connection between app and AppWeb. Setting up the trusted security token issuer is a matter of buying (or generating) the certificates and running a short PowerShell script.
What's next?
Now that we've outlined the context of what we are doing, we can get ready to install our provider-hosted app. I'll discuss this in my next blog.