Developing Low Trust Provider Hosted Apps with SAML Authentication in SharePoint 2013

Low trust provider hosted apps in a SAML secured SharePoint web application is a scenario that did not work when SharePoint 2013 was released. Things have changed fortunately, so here's a quick run down on what you need to do in order to build these apps on premises. The first thing you need to do is to apply the April 2014 CU or later.

Once you’ve applied that you’ll need to decide how you want to configure authentication on your provider hosted apps. Generally you’ll find the best approach is to use a single host for your provider hosted apps, install each app into its own subdirectory, and use an authentication mechanism that is the same as you use for your SharePoint web applications. There may be cases where you might not want to do that; for example, if your SharePoint web applications use multi-factor authentication, you may not want your users to have to enter their credentials again – twice – when they use an app that is part of a SharePoint site to which they’ve already authenticated. As explained in the beginning, that’s okay – you can use a different authentication mechanism if needed for your low trust provider hosted app because the user identity is maintained by SharePoint even after the user authenticates to the app.

When the provider hosted environment is configured, the next thing you need to do is create a ServicePrincipal with your Office 365 tenant. The Office 365 tenant uses a special version of Access Control Services (ACS) that is responsible for providing the tokens (context, refresh and access) that low trust SharePoint apps use to authenticate and authorize with SharePoint. The process overall is described in greater detail in this blog post: https://blogs.technet.com/b/speschka/archive/2013/07/29/security-in-sharepoint-apps-part-3.aspx. More importantly, MSDN has published instructions and a script you can use to create the ServicePrincipal and configure it to allow the ServicePrincipal to issue tokens to a SharePoint web application. You can find the MSDN article here: https://msdn.microsoft.com/en-us/library/dn155905.aspx. When you create your ServicePrincipal, you need to add the hostname of every SharePoint web application in which you want to use apps to a collection of SPNs on the ServicePrincipal, i.e. ServicePrincipal.ServicePrincipalNames. In the MSDN article it includes a script at the bottom that will enumerate all of the web applications in your farm and add the hostname of each one to the ServicePrincipalNames collection. However, if you add a new web application in the future, you also need to remember to go and add the hostname of the new web application to the ServicePrincipalNames collection. If you don’t do that, then apps that are installed in that web application will not be able to get a valid token.

Another option that can be used so you don’t have to revisit your ServicePrincipalNames collection is to add a wildcard. If all of your SharePoint web applications use a common domain for the host name then you can just add a wildcard for the domain. For example, if you have two web applications – portal.contoso.com and intranet.contoso.com – then you can just add a "*.contoso.com" wildcard to the ServicePrincipalNames collection. Here’s a PowerShell example of how to do that:

 

#you will be prompted to enter the credentials of an o365 Global Admin here

connect-msolservice

$spoid="00000003-0000-0ff1-ce00-000000000000"

$p = Get-MsolServicePrincipal -AppPrincipalId $spoid

$spns = $p.ServicePrincipalNames

$spns.Add("$spoid/*.contoso.com")

Set-MsolServicePrincipal –AppPrincipalId $spoid –ServicePrincipalNames $spns

 

After you’ve completed creating and configuring the ServicePrincipal, you can begin deploying your low trust provider hosted applications on SharePoint web applications that are secured with SAML authentication.