I was working on a project recently with an interesting issue. The organization has an on premise SharePoint farm. They are developing Apps for SharePoint that will leverage the server-to-server trust approach (a.k.a. S2S or High-trust) for authenticating the apps. I was engaged to help troubleshoot an "Access Denied" error when testing the app in a QA/Staging environment. So we started the troubleshooting. What follows is a dump of links that help with this troubleshooting process. Bing/Google will include these, but I'm storing them on my blog for my future use.
- More TroubleShooting Tips for High Trust Apps on SharePoint 2013 (S. Peschka)
- Creating High Trust SharePoint Apps with Microsoft Office Developer Tools for Visual Studio 2012 - Preview 2 (K. Evans)
- Configure an environment for apps for SharePoint (TechNet)
- How to: Package and publish high-trust apps for SharePoint 2013 (TechNet)
In case you are interested, what I found in this particular environment was three items:
- While the certificate used to sign the S2S tokens was trusted by SharePoint, the certificate had a signing chain that was not. Every cert in the chain, all the way up to the Root CA, must be trusted by SharePoint.
- The issuer id that was used in the Publish Wizard was entered with both the specific issuer id and the realm id. The value entered was two GUIDs with an "@" sign. Only the specific issuer id (the GUID before the "@") is necessary if you are sharing a cert across apps.
- The IIS server was not authenticating the user. The remote web was allowing anonymous access. When the app made a call back to SharePoint, which was facilitated by TokenHelper's CreateUserContextForSPHost() method, the user identifier was an empty string. So of course, SharePoint rejected the call because it could not verify that the user had permission to the site.
As a side note, I was able to verify that the S2S configuration was correct by changing to app-only permissions.
Having fixed the issue, I was on my out the door when an interesting question was raised. A large portion of the user community will be on mobile devices and not on the corporate network. If we need the remote web to authenticate the user, what will that look like? The answer is two logon prompts. One for SharePoint and one for the remote web. And as you can imagine, that user experience is sub-optimal.
Fixing this identity problem is not trivial, and I'll try to cover some of those points in the future. But the moral of the story – be sure to plan for authentication at the beginning. You should understand how every piece of your solution will authenticate and authorize users. And you should be prepared to bridge any gaps that you find in the AuthN/AuthZ story. It is very important, and can be very difficult.