Is it possible to create a SharePoint provider-hosted low-trust add-in that works with an on-premises ACS?

Question

This question is about using provider-hosted add-ins on-premises that use the low-trust authorization model - without requiring internet access.

Provider-hosted low-trust add-ins need a connection to Azure ACS and the farm needs to be registered in the cloud.

Quote from MSDN:

To use the low-trust system, the SharePoint Add-in must first be registered with Azure ACS [...]

Thus the on-premises farm needs to have internet access and the add-in needs to talk to ACS.

But what about farms without internet access? Is it possible to have kind of an on-premises ACS, that participates in the token flow?

(And yes, I know about high-trust add-ins but these are not feasable for my scenario since I need tokens that are bound to a user's identity. The add-in needs to act on behalf of the logged in user (e.g. do security trimmed search requests). To my understanding this is not possible with high-trust add-ins since there is no token. Correct me if I'm wrong here.)

Answer 1

When using high trust, you are using the same JWT tokens. The difference is that in high trust system, your app is so cool and so trusted, that SharePoint trusts your app for token generation.

Actually your app generates and signs tokens. That's why this system called high trust (compare to low-trust, when SharePoint have to trust third-party Azure ACS).
If you open TokenHelper.cs, you can find following lines (IssueToken method):

string accessToken = new JsonWebSecurityTokenHandler().WriteTokenAsString(jsonToken);

This is actual code which generates and sings token with your certificate. SharePoint then trusts this token since you added public part of the certificate as part of the high-trust configuration. This accessToken is your token bound to the user. A few lines before there is actorTokenString - this is your app-only access token, all produces by your app and trusted (high-trusted :) ) by SharePoint.

UPD
All you need in order to create this token bound to the user, is user's SID from active directory, usually that's a string in format 'S-1-5-21-1976753858-2077894621-3616986626-500'.
TokenHelper.cs uses this string later for token generation in high trust scenario. User's SID can also be easyly obtained for any user in the AD by few lines of .net code, that also means that you can run "elevated" search queries using any user identity.

UPD2
Answering on the original question regarding on-premise ACS, it's not possible to run on-premise ACS.

Answer 2

For On premise SharePoint farms, you need to create High trust Add-ins which uses S2S authentication mechanism. And you can run code on logged in user context using High trust add-ins.

For SharePoint online , you need to create Low trust add-ins with ACS and the remote add-in needs to be able to communicate with MS Azure ACS of the respective office 365 tenant. There is no on-premise version of ACS. So the on-premise remote server should have firewall rules to have connectivity with the Azure ACS

Answer 3

As far as the question is concerned: it seems to be impossible to run ACS on-premises. Thus the add-in somehow has to talk to Microsoft's servers.

---

Nonetheless, I was able to impersonate arbitrary users with a high-trust add-in as well, thus my immediate need to use a low-trust add-in for this purpose is gone.

For sake of completeness here is how to impersonate a user using a high-trust provider-hosted add-in.

In a newly created add-in replace the following lines

var spContext = SharePointContextProvider.Current.GetSharePointContext(HttpContext);
using (var clientContext = spContext.CreateUserClientContextForSPHost())

with this code, that creates a ClientContext using a specific user account:

var hostUrl = SharePointContext.GetSPHostUrl(HttpContext.Request);
var identity = new WindowsIdentity("developer"); // insert user login name here
using (var clientContext = TokenHelper.GetS2SClientContextWithWindowsIdentity(hostUrl, identity))

Now everything the add-in does in SharePoint is done as the given user account, "developer" in this case.

Note: this change makes the add-in incompatible with SharePoint Online.