On-Premises Claims Authorized SharePoint and Hybrid Apps in Azure

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

I recently needed to deploy a SharePoint-hosted App that would work in both SharePoint Online and On-Premises. My client had an Azure license, and we are hosting the App there. Now, how to get the On-Premises farm to work with my App? I started by reading this MSDN article on the subject.
This article had 90% of the information required, and as usual the other 10% is where the hair pulling happens. Here, I will attempt to fill in the other 10%.

1. Patch your environment to the November 2014 CU for SharePoint Server. There are fixes in the August CU that affect this configuration and without them it will not work. Why the November CU then? Just take a look at the August install instructions and you will see why. If for some reason you cannot do the November CU the August will work, but set aside a day.
2. Your Claims Provider class needs to implement the SupportsUserKey property, the GetClaimTypeForUserKey method and the GetUserKeyForEntity method. If you are using the Codeplex project Claims Provider Here and are using ADFS for your STS then you are fine. I had one that was upgraded from 2010 and had these methods and property missing and that left for lots of hair pulling.

   public override bool SupportsUserKey
   {
       get { return true; }
   }
   public override string GetClaimTypeForUserKey()
   {
       return Microsoft.IdentityModel.Claims.ClaimTypes.Upn;
   }
   protected override SPClaim GetUserKeyForEntity(SPClaim entity)
   {
       if (entity.ClaimType == this.GetClaimTypeForUserKey())
       {
           return entity;
       }
       else
       {
           string token = OperationContext.Current.RequestContext.RequestMessage.ToString();
           XmlNodeList claimList = GetClaimsList(token);
           XmlNode upn = claimList.OfType<XmlNode>().Where(c => c.Attributes["AttributeNamespace"].Value.ToLower() == "http://schemas.xmlsoap.org/claims" && c.Attributes["AttributeName"].Value.ToLower() == "upn").FirstOrDefault();
           return new SPClaim(Microsoft.IdentityModel.Claims.ClaimTypes.Upn, upn.InnerText, AdClaimValueType, SPOriginalIssuers.Format(SPOriginalIssuerType.TrustedProvider, SecureStoreClaimsSettings.Default.ProviderName));
       }
   }
   

3. The User Profile Service needs to be completely set up and functioning. The OAuth procedure with Apps uses the UPA to match the string value of user ID from the token to look up and rehydrate a user in SharePoint so that it can operate on its behalf. If it can’t find the user in the UPA you will get a 401 when the app requests information.
4. If, like me, you are working in a development environment and have deployed Apps that are now not working I would recommend deleting any App Catalogs and your App Management Service and rebuilding them as corrupted App installs were giving me some issues.
5. The PowerShell scripts listed in the above article seemed to be a bit out of date. Steve Peschka made some updates to them on his blog, but the MSDN article does not seem to have those updates. I have combined the 4 steps listed in the article along with Steve’s updates into one script with step by step instructions that I hope will help the next guy. The scripts can be found here.
6. Deploy your App to you App Catalog and cross all available limbs.

Sources for this post:

• Updating Trust Between OnPrem Farms and ACS for Apps When Your SharePoint STS Token Signing Certificate Expires
• How to: Use an Office 365 SharePoint site to authorize provider-hosted apps on an on-premises SharePoint site
• helpful post to understand how to debug OAuth issues Inside SharePoint 2013 OAuth Context Tokens