Share via

Security in SharePoint Apps - Part 2

  • Article

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

Comments

  • Anonymous
    January 01, 2003
    thanks for sharing.

  • Anonymous
    January 01, 2003
    thanks

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    July 29, 2013
    It is worth noting that App Only Policy requires OAuth to generate the tokens and hence it cannot be used in SharePoint Hosted Apps. It can only be used in Auto Hosted and Provider Hosted Apps.

  • Anonymous
    May 23, 2014
    @Vardhman - With Provider Hosted and Auto-hosted you have to cross the process boundaries requiring you to prove your identity where as with SP Hosted Apps, it's all happening within the same process where you have already authenticated yourself. Still, I would believe so, although we don't have the Token generation available, who knows we get the same in one of the exposed API's down the lane, considering we do have the App having it's own identity elements already.

  • Anonymous
    September 18, 2014
    The comment has been removed

  • Anonymous
    March 02, 2015
    PREVIOUS: Security in SharePoint Apps - Part 2
    In the first two parts of this series we looked at