I recently put together a session around security in SharePoint Apps. There seems to be enough content on this topic to keep people on their toes at all times, so I decided to try and assemble all this information all in one place on this blog with a series of posts. Most of this information is scattered around on various pages on TechNet and whatnot, so hopefully at least some of this content will sound familiar. I’ll also include some sample code and/or projects along the way to help illustrate a point. Also, as I continue to add parts I’ll try and come back here each time and update the set of links to all the parts in this series:
- Security in SharePoint Apps - Part 2 (understanding security contexts for requests)
- Security in SharePoint Apps - Part 3 (setting up low trust on premises)
To begin with, I think it’s useful to establish a common understanding of one of the main actors in SharePoint App security, which is the App Principal (AKA SpAppPrincipal). Everyone should be familiar with a User Principal at this point – that concept has been around since the first version of SharePoint shipped in 2001. User Principals are represented by claims of different types, such as my Windows account, my email address, my Active Directory group, etc. We see User Principals in various formats, such as:
- microsoft\stevep
- fbaMembers:stevep
- i:0e.t|aad|stevep@microsoft.com
We manage rights for user principals by adding them to SharePoint groups, adding them to Permission Levels, augmenting their claims, etc.
So what is an App Principal? This is probably best explained by way of a little story, and it goes something like this. Suppose I have a SkyDrive site. I keep all of my documents and pictures up there. When I want to access that content I have to enter my username and password. SkyDrive validates my credentials and then gives me access to that content.
Now suppose I start using another cloud service; it’s called Contoso Photo and I want to use it to print out pictures that I store on SkyDrive. To access Contoso Photo, I also have to enter a username and password, and it has to validate that before it lets me use their services. So I have these two services I use, they both use a username and password, and I need to share data between them – how do I do that?
Well, one option would be that I could give the credentials I use for SkyDrive to Contoso Photo. That sounds scary – and it is. What’s even scarier is that there are some services out there that ask you to do exactly that. So let’s play that scenario out a bit though and see how it works. Now when I ask Contoso Photo to print a picture for me, it can ask for those resources from SkyDrive. It will present my username and password to SkyDrive, and SkyDrive has no idea that it isn’t me. It just sees a valid set of credentials and it knows that those credentials have rights to View the pictures so it hands them off to Contoso Photo.
The thing is though, I have a lot more rights than just being able to view content. I can add content, tag content, add comments, etc. Now that Contoso Photo has my credentials it can do all of that on my behalf as well. You of course hope that Contoso Photo takes their reputation seriously enough that you don’t have to worry about that happening, but it’s certainly an unsettling position to be in.
Now what happens if I decide I don’t want to use Contoso Photo anymore? Well I could go back and change my password to SkyDrive. In fact Contoso Photo would also have rights to change my password with SkyDrive, but hopefully they would never do that. But what if I had 10 cloud services I was using that were configured the same as Contoso Photo? I would have to go back then and change my SkyDrive credentials in 9 other places, once for each of those other services I wanted to continue using. As you can imagine, it creates a real mess.
So what if I took a different approach. Suppose I created something for Contoso Photo that it could give to SkyDrive – let’s call it a “note”. In that particular note, I’m going to say that Contoso Photo is allowed to View my photos in SkyDrive, and that’s it. I’m going to sign that note and then Contoso Photo is going to give it to SkyDrive when it needs to access my photos. SkyDrive looks at the note and sees that it says Contoso Photos can access Steve’s photos. It also sees that the note is signed by Steve, so it knows that the note is legitimate.
In a nutshell, that “note” process is how you can think of an App Principal. It describes how an application is able to separately identify itself from a User Principal, and describe exactly what it can do separately from what the User Principal can do. It also shows how the App Principal can act on our behalf without needing our credentials each time it needs to talk to SharePoint. SharePoint knows that it can trust the request from the App Principal because the requests it makes are “signed” by somebody it trusts – something we call a “trust broker”, which will discuss in a subsequent post.
That really is what I wanted to cover in part 1 – establish a common understanding of what an App Principal is, because it is one of the main actors when working with data in SharePoint. Note that I did not say ALL the actors. I’ll go into the further explanation on that in Part 2 of this series.
NEXT: Security in SharePoint Apps - Part 2