Security in SharePoint Apps - Part 6
PREVIOUS: Security in SharePoint Apps – Part 5
As promised, in this part of the series we’re going to talk about the big dogs of App security – those options that you can use to let you do anything, anywhere with your content. Specifically we’re going to look at App Only policy apps, and tenant level permissions. Either by themselves or used together they provide a powerful option for Apps.
As described in Part 2 of this series, there are four possible security contexts when a request comes into SharePoint. One of those contexts is an App Only context. When SharePoint uses an App Only context it really doesn’t matter what rights the end user has on the content – all that matters is what rights have been granted to the App.
Because the App can effectively run with “elevated privileges” (i.e. more rights than the user might have), it requires you to be a Site Collection Administrator to install. Another thing worth pointing out is an App Only app will work with both low trust and high trust environments. Actually creating an App Only context in your CSOM calls is a bit “unusual” compared to how you would do it in every other scenario. Kirk Evans has actually blogged about the semantics quite nicely at https://blogs.msdn.com/b/kaevans/archive/2013/02/23/sharepoint-2013-app-only-policy-made-easy.aspx. Where it all happens is when you create your access token – you want to pass a null value for the Windows identity. For example, in my high trust app this is the line of code where I create my access token for an App Only app:
string appOnlyAccessToken = TokenHelper.GetS2SAccessTokenWithWindowsIdentity(hostWeb, null);
There is also support in the ClaimsTokenHelper class, which is used when working with SharePoint sites that use SAML and FBA (see here for more details: https://blogs.technet.com/b/speschka/archive/2012/12/07/using-sharepoint-apps-with-saml-and-fba-sites-in-sharepoint-2013.aspx). In that case you would create your client context like this (the last parameter indicates whether it should generate an App Only token or not):
var clientContext = TokenHelper.GetS2SClientContextWithClaimsIdentity(sharepointUrl, HttpContext.Current.User, TokenHelper.IdentityClaimType.SMTP, TokenHelper.ClaimProviderType.SAML, true);
An easy way to demonstrate this can be done using the one of the sample apps attached to this posting – AppOnlyPolicyApp.zip. What I typically do to demonstrate this is create a document library and change the permissions on it so only site administrators can see it. Then I log into the site as an administrator to verify I can see it, then use the App to show that it can retrieve the content. Then I’ll log into the site as a non-admin and verify that I cannot see the library when I’m browsing the site; however when I use the sample App I’m able to retrieve all lists and libraries and see what is contained within the specially secured one. So for those cases in the past where maybe you used something like SPSecurity.RunWithElevatedPrivileges, the App Only option is a logical replacement and does not require full trust code.
The other feature that I wanted to call out in this section is tenant-level rights. In most cases when you select the permissions your application requires, you will select some Web or List level right. What if you want to be able to work with content in any site collection in your tenant or farm though? That’s where the tenant level permission comes into play. Like the App Only scenario, you can use tenant level permissions with either a low trust or high trust application. When you select a Tenant level permission in the AppManifest, you decide whether you want Read, Write, Manage or Full Control. There are a couple of important things to be aware of though:
- If you ask for Tenant level Full Control rights, you cannot deploy it as a low trust application. Full Control Tenant rights are ONLY available for high trust apps.
- Even though it’s not obvious by the permission name, Tenant level rights include more than just list and library content. It also grants you permission to things like social feeds and others. In fact if you try and grant your app both Tenant permissions and Social Feed permissions, it will come back with an “unauthorized” response when you try and access the content. It’s rather ironic really – you have more rights than you need, therefore you are unauthorized to enter.
One of the other things that’s interesting about tenant level permissions is the deployment model. You only have to install the App into a single site collection, but after you do that you can use it to access content from any site collection in the farm or tenant. That’s kind of an interesting distinction between tenant permission and App Only permission Apps.
- Tenant permission apps only need to be installed once, then they can be used everywhere. App Only apps have to be installed in each site collection in which you want to use it.
- App Only permissions don’t use the permissions of the current user, it just uses the App permissions. Tenant level permissions still requires that the current user has whatever rights the App is asking for in that site collection.
So of course…if you REALLY want an all-powerful application…the thing to do would be to combine these two attributes! Yes, you can do that too. So what you end up with is an App Only application that has Tenant level permissions. You get the best of both worlds then, because you can install the App once and it will work against any site collection. Not only that, but it will have whatever rights you asked for (all the way up to Full Control) because the user context will not be used when trying to access content. It has almostas much power and flexibility as a custom timer job that you would write with full trust code. The only difference of course is that you’re limited to what the CSOM API can do, versus having access to the entire object model including the administrative APIs.
There’s one last comparison worth making here. If you read the previous part about permission on demand (POD) apps, you saw that you also didn’t really have to “install” it in each site collection to use it. You can also ask for whatever rights you wanted at run time. That sounds kind of similar to an App that uses tenant level permissions (TLP), so let’s look at some of the differences:
- POD apps only work with low trust; TLP works with both low and high trust. Exception that proves the rule: unless you ask for Full Control TLP, in that case it can only be used by high trust apps, not low trust. Yikes.
- TLP apps have to be installed and trusted once, then they can be used everywhere by everyone. POD apps have to be "used" the first time by a site collection owner; after that it can be used by any user. That makes the deployment quite tricky.
- Once installed anyone can use a TLP app. A POD app can be used by anyone, but only if a site owner uses it first so it can be trusted and installed in the site.
That wraps up this discussion of App Only Apps and tenant level permissions. In the next section we’ll take a closer look at the plumbing required for high trust apps.
NEXT: Security in SharePoint Apps - Part 7
Comments
- Anonymous
January 01, 2003
thanks for sharing. - Anonymous
January 01, 2003
The comment has been removed - Anonymous
January 01, 2003
thanks - Anonymous
October 25, 2013
The comment has been removed - Anonymous
December 15, 2013
Pingback from Security in SharePoint Apps - Part 6 - Share-n-dipity - Site Home ... | ARB Security Solutions - SharePoint Security Solutions - Anonymous
December 16, 2013
PLEASE NOTE: THIS IS STRICTLY A CONCEPT THAT I HAVE UTILIZED AND MAY/MAY NOT CONFIRM TO OFFICIAL - Anonymous
March 02, 2015
I recently put together a session around security in SharePoint Apps. There seems to be enough content - Anonymous
March 02, 2015
PREVIOUS: Security in SharePoint Apps – Part 4
As promised in Part 4, there’s actually - Anonymous
March 02, 2015
PREVIOUS: Security in SharePoint Apps – Part 6
In this part of the series, I’m going to