PREVIOUS: Security in SharePoint Apps - Part 2
In the first two parts of this series we looked at what an App Principal is and what the security context is that we use when a request comes into SharePoint. Now that we have those basic components of the framework defined, let’s talk a little about the types of trust we use for Apps in SharePoint. We have two types of trusts for apps in SharePoint, which we call Low Trust and High Trust (sometimes also known as S2S). Now that you know about App Principals and security contexts, how do these things differ between the two trust models?
In the low trust model, SharePoint provides a context token, that includes a refresh token, that has information about who the user is what the App is. The App can use the refresh token to get an access token, and the access token is what’s actually presented to SharePoint when the request is made. Remember in Part 1 when I described handing SharePoint a “note” that said what the App is and what it could do? That is the role of the access token.
In a high trust model, the App tells SharePoint who the App AND who the user is. How your App comes up with the user identity is completely up to you – but we will talk about this more in the part on high trust apps.
We can use either low trust or high trust with on-premises applications. For purposes of our discussions you can use only low trust Apps when they are deployed to Office 365. Each one uses different plumbing to work though, and we’ll look a little at the low trust plumbing for an on-premises SharePoint farm next (there’s no point in looking at it for Office 365 because it’s already configured for you there).
When you use low trust Apps on-premises, you’re deferring to ACS to act as a trust broker. I would define ACS for you, but the acronym keeps changing on me…to me it will always mean Access Control Services but now it’s Azure something something. J Remember I mentioned the “trust broker” concept in Part 1. You can think of the trust broker as the intermediary between SharePoint and your App. SharePoint and your App both trust the trust broker, and it becomes something like a transitive trust in Windows Server – A trusts B and C trusts B, so therefore A trusts C. So in a low trust app ACS is the trust broker; when we talk about high trust apps we’ll see how a simple certificate can become a trust broker.
To configure your on-premises farm to be able to use low trust apps, there are a few steps you need to take:
Okay, so on the previous two steps here I did not give you a lot of detail about how to do them, but there’s a reason for that. We have a nice document already prepared that includes more details and a PowerShell script to take care of this for you. All you have to do is go to http://msdn.microsoft.com/en-us/library/dn155905.aspx to more details and download the script from there. A couple of other things worth noting about this:
Once you’ve done these steps – which when you think about it are really pretty simple; open a browser and create a tenant, copy some PowerShell script and run it, then reboot your server – you’re ready to write your first low trust app on-premises. Doing so is actually quite simple:
Here’s how it looks running through the wizard:
And that’s all there is too it. If it all doesn’t “just work” for you though, here are a few troubleshooting tips:
That wraps up this post. In the next post we’ll look at the context token from SharePoint in a little more detail and see what you can do with it.
NEXT: Security in SharePoint Apps - Part 4