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.)

3 Answers 3


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.

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.

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

  • Sounds exactly like what I need. Will try this out! Commented Nov 12, 2016 at 11:03
  • Thanks, you pushed me in the right direction - see my own answer for details. Unfortunately I still need an answer regarding the "ACS on-premises" part. Are you confident that this is not possible? If yes, please add it to your answer and I'll accept it. Commented Jan 19, 2017 at 12:24
  • Done. Glad to know everything works for you! Commented Jan 19, 2017 at 12:35

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

  • 1
    So there is no low-trust variant that works "offline", but it's still possible what I actually want to achieve since I'm able to impersonate with high-trust. Cool. Commented Nov 12, 2016 at 11:05
  • If you are working on SharePoint online, then high trust is not possible only low trust add-ins are possible
    – Unnie
    Commented Nov 12, 2016 at 11:15
  • I'm targeting an offline on-premises farm. Commented Nov 14, 2016 at 7:53

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.