So I thought I had the ACL-thing down pretty well, but it doesn’t seem to work for me :-(. I’ve got a service (X) with an execute ACL of, say, myACL. myACL allows the groups ‘Administrators’ and ‘myUsers’ execute permissions. I also have a user ‘myUser’ in the group ‘myUsers’. So ‘myUser’ should seemingly be able to execute X.
Now on another server I have a Remote Server Alias defined to log in to the original server as ‘myUser’. Tested this and it connects successfully. However, when I try to pub.gd.remote:invoke X on the original server I get an “Access Denied, Authorization Required” exception. When I add myUser to the ‘Administrators’ group everything works fine.
Did you try invoking the service you’re trying to use in the remote invoke locally, with user myUser? For instance, from the Developer, use “Test -> Run in browser” and use myUser for the username. If this fails, one of the services invoked inside service X might have a stricter ACL on them and the Enforce option to Always (instead of "For top-level service only).
If you can invoke this service properly from the browser, the problem might be that the ACL set on the remote server alias is set too strict. This ACL setting (in the screen where you define the remote server alias) defines the users who are allowed to use his remote server alias definition.
OK, … so I give up for the time being on this one. I haven’t had a chance to thoroughly investigate this further (in weeks, obviously) and more pressing demands are still pressing. Thanks though, Koen, for the pointers.
FWIW, the problem is not the ACL on the alias itself, that’s been tested and would have manifested itself differently (I believe). I’ve had mixed results with access control over the last couple of weeks though. This very same scenario appears to have worked on occasion, while I’ve had bizarre problems with TN on the other hand. I was using an HTML form to submit a doc to TN, as I’ve done many times previously on the same server with the same creds, and got AccessDenied. Tried this from a new browser session/the next day/whatever and it worked fine again.
Don’t know what’s up exactly, but when I get back around to it I’ll look into it more.
You are not alone. We also experience occassional “Access Denied” error from the service pub.gd.remote:invoke X. For some clients we do not use GD, havent had this problem. I guess, GD service in webMethods have some problem still lingering around.
Try increasing the log level to see what service is actually giving the access denied, then review what user it’s trying to authorize. This should help you resolve the issue.