Related / follow up to this question.

Because a site's email settings (SMTP server, "from" address, etc.) are not available through any client-side APIs, I created a mini WCF web service that is deployed to the ISAPI folder. It takes a site's URL as a query parameter, and uses that to open SPSite and SPWeb objects in server side code, retrieve the email settings, and then return that in a simple JSON payload.

It works perfectly fine when I test it from Postman.

But the main reason I need it is because I need to use the HttpSend web request action inside a VisualStudio declarative custom action (.xaml file) in order to get those settings and send them on into a custom code activity run by Workflow Manager. (I've gotten CSOM code to run inside the custom code activity, but again, I can't get those settings from any client APIs.)

I'm used to the general rule that a workflow will run with the permissions of the person who initiated it, but when I test my workflow and it gets to that step, I'm getting a 401 UNAUTHORIZED. And not only that - as one of the first lines in my web service method, I log to ULS that the web service was invoked. I can see those log entries from the times that I invoke the web service from Postman, but I don't see them for when I tried it with the workflow. Which means to me that it's not even choking on the part where I SPSite site = new SPSite(siteURL). It's not even getting that far because the initial log entry isn't there.

So... what permissions do I need to set up to enable a workflow to invoke a custom WCF web service at <site>/_vti_bin/path/to/service.svc?

I'm no expert at WCF, so I haven't set up anything that I can see around authentication/authorization there. Do I need to do something explicit there? (Why would I, if it works for me from Postman as it is currently set up?)

Do I need to set up workflows to run with elevated permissions using the whole app permission model? If so, what would the minimum permission level need to be just to get the WCF service to run? I'd rather not give workflows full control on the site, and I have no problem using SPSecuity.RunWithElevatedPrivileges inside the web service to retrieve the values I need, as long as I can get it invoked in the first place.

1 Answer 1


As I posted as an answer to my other question about this, it doesn't seem to be about setting permissions on the custom web service or granting any extra permissions to the workflow service.

Apparently the workflow service will automatically include an Authorization: Bearer header with a blank bearer token if no Authorization header is explicitly set up, which in turn causes IIS to reject the request as unauthorized.

The solution is to explicitly add a header Authorization: "" to the call to my custom web service, which makes IIS allow the anonymous request.

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.