PREVIOUS: Security in SharePoint Apps - Part 1
In Part 1 of this series I described how to think about an App Principal, and I mentioned that it is one of the main actors in determining who has rights to what content. The other actor, of course, is the User Principal. Between the two though, there are four possible security contexts that SharePoint may use when responding to requests for content. In this post we’ll take a look at all four and how we determine when we use which.
It’s best to look at the process of determining the security context through a familiar paradigm, like a flowchart. So here’s how our flowchart would look – our starting point is a request coming in to SharePoint, and we’ll take it from there.
- Have user credentials been provided?
- YES: If user credentials are included, then the next thing we look at is where is the request going – is the request for an App Web (i.e. like a SharePoint-hosted app)?
- NO: If the request is not for an App Web, then that means it’s for a content web. In that case, it’s like SharePoint as you have always known it – a user trying to get something out of a SharePoint site. In that case we set a User Only security context with the request.
- YES: If the request is for an App Web, then it means that there is both an App AND a User that we need to add to the security context for the request. In that case we set a User + App context to the request.
- NO: If user credentials were not included, then the next thing we need to determine is whether an App token was provided?
- NO: If there’s no user credentials and no App token, then we’ve got no security context whatsoever. That’s okay – it just means that this is an Anonymous request. That’s a completely valid scenario of course, that we frequently use on Internet-facing sites.
- YES: If there’s an App token, then we need to take a closer look at it and ask, is there a user identity included with it?
- YES: If there is a user identity included with it then it means that the App is acting on behalf of that user. You will in fact see that sometimes when a list item is modified by an app for example – it will say something like “Modified by Contoso App On Behalf of Sam Jones”. In this situation then we treat it like a scenario above and set a User + App context to the request
- NO: If there is ONLY an App token without any user identity, then we view it as making what’s called an App Only request. App Only apps execute with elevated privileges, and can operate on data whether the current user has rights to it or not. The only check that’s made is whether the App has rights to the content.
So those are the four identity contexts that we can have when making a request for content from SharePoint. They’re important to know, because we can wind up in any of them when writing apps in general…but for purposes of this series we’re really just going to focus on User + App and App Only requests. To make it a little easier to rationalize, here’s a picture of the flowchart I described above:
In the next post in this series we’ll talk about the simplest environment to write code in – an on-premise Low Trust App.
NEXT: Security in SharePoint Apps - Part 3