webMethods 10.3 Integration Server encountered an ACL error: "Access Denied"

,
1

We are using webMethods 10.3 and the fixes versions are:IS_10.3_SPM_Fix4，IS_10.3_Core_Fix19

We encountered an “Access Denied” error when invoking a flow service,but in fact we have permission and most of the time it is normal. It only occasionally throws this error.The following is the detailed error message：

com.wm.app.b2b.server.AccessException: [ISS.0084.9004] Access Denied
at com.wm.app.b2b.server.ACLManager.process(ACLManager.java:261)
at com.wm.app.b2b.server.invoke.DispatchProcessor.process(DispatchProcessor.java:34)
at com.wm.app.b2b.server.AuditLogManager.process(AuditLogManager.java:401)
at com.wm.app.b2b.server.invoke.InvokeManager.invoke(InvokeManager.java:638)
at com.wm.app.b2b.server.invoke.InvokeManager.invoke(InvokeManager.java:447)
at com.wm.app.b2b.server.invoke.InvokeManager.invoke(InvokeManager.java:405)
at com.wm.app.b2b.server.ServiceManager.invoke(ServiceManager.java:253)
at com.wm.app.b2b.server.BaseService.invoke(BaseService.java:236)
at com.wm.lang.flow.FlowInvoke.invoke(FlowInvoke.java:267)
at com.wm.lang.flow.FlowState.invokeNode(FlowState.java:668)
at com.wm.lang.flow.FlowState.step(FlowState.java:534)
at com.wm.lang.flow.FlowState.invoke(FlowState.java:501)
at com.wm.app.b2b.server.FlowSvcImpl.baseInvoke(FlowSvcImpl.java:1150)
at com.wm.app.b2b.server.invoke.InvokeManager.process(InvokeManager.java:768)
at com.wm.app.b2b.server.util.tspace.ReservationProcessor.process(ReservationProcessor.java:46)
at com.wm.app.b2b.server.invoke.StatisticsProcessor.process(StatisticsProcessor.java:54)
at com.wm.app.b2b.server.invoke.ServiceCompletionImpl.process(ServiceCompletionImpl.java:250)
at com.wm.app.b2b.server.invoke.ValidateProcessor.process(ValidateProcessor.java:49)
at com.wm.app.b2b.server.invoke.PipelineProcessor.process(PipelineProcessor.java:171)
at com.wm.app.b2b.server.ACLManager.process(ACLManager.java:326)
at com.wm.app.b2b.server.invoke.DispatchProcessor.process(DispatchProcessor.java:34)
at com.wm.app.b2b.server.AuditLogManager.process(AuditLogManager.java:401)
at com.wm.app.b2b.server.invoke.InvokeManager.invoke(InvokeManager.java:638)
at com.wm.app.b2b.server.invoke.InvokeManager.invoke(InvokeManager.java:447)
at com.wm.app.b2b.server.invoke.InvokeManager.invoke(InvokeManager.java:405)
at com.wm…

Does anyone know the reason? How can we solve this problem?

2

A couple of hints

  • 10.3 Core Fix 19 is quite old, the latest one is Core Fix 28, you could check if the issue resolves with later versions.
  • “most of the time it is normal. It only occasionally throws this error” - is there some external auth configured that could fail?
  • I would suggest setting facilities for Authentication , HTTP Header, request , response to trace in the Admin UI-> server logger and check the logs.
  • After the error, how does it start working again, is there a server restart needed?

-NP

1 Like
3

Without extra information we can only guess. What kind of authentication have you implemented. Are you using LDAP or IS internal account? Is it a service account? Is the account used elsewhere? Is the user blocked after getting that error? With the information we have, only reason I can think of is user is blocked somewhere else and getting access denied errors on IS. I would find out which user is failing and where it is stored first. If the user is used somewhere else other then integration servers, I would recommend creating another user for only IS usage.

1 Like
4

Thank you for your reply.

The scenario where this error occurs is that we invoking a flow service through the ‘com.wm.app.b2b.server.Service.doInvoke’ method in a javaService，and both services are located within the same Integration Server.

We have not configured external auth configured that could fail，nor have we added any extra permissions or users，all configurations are using the default settings.

When an error occurs, only the specific data at that moment is lost and not processed. Other data is still handled normally, and there is no need to restart the server.

5

This certainly sounds like a client issue. Is the failed request send from the same endpoint with the successful ones? Not just end point but the same code block. There may be 2 different code blocks that calls that service and one can have a different credential setting. I also recommend installing latest fixes, it usually fixes most of the environment issues and since 10.3 is quiet old, these kind of bugs should have already been fixed by now. Also note that 10.3 is too old, you need to upgrade your environment as well (for receiving support and having access to latest security practices).

6

I would suggest to create a repro package. Or least show us the code here. I am sorry, but this is by far not enough information to provide any guidance.

Others have provided good advice and asked good questions. But without more information either approach can only be “shooting into the dark”.

1 Like
7

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.