What Happens When a Client Runs a Service with ACLs?
When a client requests that Integration Server invoke a service, the server checks the ACL assigned to the service. If the client is a member of an allowed group and is not a member of a denied group, the server executes the service. If the client is not a member of an allowed group, the server denies the request to invoke the service and stops executing.
By default, when a client requests a service,
Integration Server checks only the ACL of the externally invoked service (the service requested directly by the client). The server does not check the ACLs of any of the internally invoked services (those services invoked by the externally invoked service). However, you can set up the security settings for a service so that
Integration Server checks the ACL assigned to the service
every time it is invoked, whether directly by a client or by another service. For details, see
Assigning ACLs.
The following diagram illustrates the points at which ACL checking occurs when a client requests a service.
Figure 30. ACL checking when a client requests a service
Stage | Description |
1 | The client (such as another application or a DSP) requests the Purch:SubmitPO service on the local webMethods Integration Server. Integration Server checks the ACL of the Purch:SubmitPO service (the externally invoked service). The server executes the service only if the client is invoking the service on the behalf of a user that is a member of an allowed group and is not a member of a denied group for the ACL assigned to the service. |
2 | The Purch:SubmitPO service invokes the Purch:LogPO service. Because the Purch:LogPO service is invoked by the externally invoked service and is located on the same server as the externally invoked service, Integration Server considers the Purch:LogPO service to be internally invoked. Consequently, the server does not check the ACL of the Purch:LogPO service before executing it. |
3 | The Purch:SubmitPO service invokes the Purch:CreditAuth service. Like the Purch:LogPO service, Integration Server considers the Purch:CreditAuth service to be an internally invoked service. Consequently, the server does not check the ACL of the Purch:CreditAuth service before executing it. |
4 | The Purch:SubmitPO service invokes the Purch:SendPO service. Like the Purch:LogPO and Purch:CreditAuth services, Integration Server considers the Purch:SendPO service to be an internally invoked service. The server does not check the ACL of the Purch:SendPO service before executing it. |
Note:
If the security settings for the
Purch:LogPO,
Purch:CreditAuth, or
Purch:SendPO services specify that ACL checking occurs every time the service is invoked (
Enforce execute ACL option is set to
Always),
Integration Server would perform ACL checking when the externally invoked service (
Purch:SubmitPO) invoked these services. For more information about requiring ACL checking, see
Assigning ACLs.
Note:
Any service that the Purch:SubmitPO flow service invokes could also be invoked directly by the client. For example, if the client directly invokes the Purch:SendPO service, the server checks the ACL of the Purch:SendPO service. If the client is invoking the service on the behalf of a user that is a member of an allowed group and not a member of a denied group, then the server executes the Purch:SendPO service.
