Sharepoint 2013 ribbon button call external machine Windows Authentication

Question

For a sharepoint 2013 application I need to create a custom button in the ribbon. When the button is pressed a request will be send to a service on another machine (WebAPI or WCF, I will create this by myself so I have the choice...). One requirement is to use Windows Authentication to authenticate the user on Sharepoint and the same identity need to be transfered to the other machine. This because a request must be made on the WebAPI-/WCF service on behalf of the user that pressed the button.

An example: User1 presses the button, a request will be made to the WebAPI/WCF service. On the WebAPI/WCF service a request must be made on behalf of User1 (to another webservice with Windows Authentication).

Does anyone know how I can achieve this. I first focussed on the solution with WebAPI and some Javascript code behind the button. But this approach doesn't support Windows Authentication... Or do I have to create a webpart that listens to a postback event, that is generated by the ribbon button? To still support Windows Authentication.

Any suggestions/alternatives will be welcome.

Answer 1

I might not be able to give you an exact answer as the solution architecture it is quite open to debate. I would not see a good practice to call the WS from ribbon button via JavaScript, but rather go for launching a dialog window, loading an Application Page. This way you get better error control, and full server-side API, therefore much easier to impersonate the 2nd user, or execute a long-running operations, while providing appropriate feedback to user - better usability for sure.

So go for creating your own solution deploying the custom action on the ribbon + custom application page - which would by default authenticate most likely current user (unless you inherit the page from UnsecuredPageLayout, etc.).

Or, if you went for the cloud-app model, than you could of course opt for using the {StandardTokens} to pass in details on your app (e.g. Provider or Auto-Hosted) could actually mean having another ASP.NET application actually taking over the control, while getting context passed on.