Access denied for SOAP request

, ,
1

We have created ACL "MercuryUsers", Group "MercuryUser" and user "mercury". MercuryUserACL is used in ExecuteACL property of webservice.

While making webservice call (HTTPS) from mercury system it is throwing below error, but it works if we setup ExecuteACL as anonymous.

Error in mercury:-

System.ServiceModel.CommunicationException: The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.

Server stack trace:

at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object ins, Object outs, TimeSpan timeout)

at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)

at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

which is consumed by our webservices for authentication

IS Error log throws below error:-

2014-10-09 13:41:16 EDT [ISC.0088.9998E] Exception → null

2014-10-09 13:41:16 EDT [ISS.0007.0001E] Access Denied. User "local/Default" does not have permissions to invoke service: JdlOrder2Invoice.outbound.ws.provider.v2.PurchaseOrder:PurchaseOrderService.

This setup is working in 8.2(i have only step it) but not working 9.6. Does any one faced this issue while migration to 9.6? Please add your inputs

Thanks
Sai

2

the “local/Default” user indicates that the authentication is not done with the “mercury” user as you intended to use.
Check if the client system pass the right credential properly.

3

Hi Sai,

Did you find any solution of this problem?

I am facing similar problem when I have exposed on provider web service to one partner in WM9.5 environment.

I have set permission
ReadACL:Anonymous
ExecuteACL::CreatedACL

Error:: Access Denied. User “local/Default” does not have permissions to invoke service:

Regards,
Kuldeep

4

To fix this issue with SOAP UI. On SOAP UI go to file-> preferences → HTTP settings → "check" Authenticate Preemptively

5

To fix this issue in 9.x version, kindly update the provider descriptor property “Pre-8.2 compatibility mode” value to “True”