Step | Description |
1 | Port access verification When Integration Server receives an inbound web service request through an HTTP/S port, Integration Server verifies that the provider web service descriptor can be invoked through that port. If access to the provider web service descriptor is allowed through the port, Integration Server proceeds to step 2, Transport-level authentication. If access to the provider web service descriptor is denied on the port, Integration Server returns an HTTP 403 response and a SOAP fault. Integration Server rejects the web service request and no further processing occurs. For more information about restricting access to ports, see the section Controlling Access to Resources by Port in the webMethods Integration Server Administrator’s Guide.
Controlling Access to Resources
by Port. Note:Integration Server does not perform port access verification for a web service request received via the JMS transport. |
2 | Transport-level authentication. When Integration Server receives an HTTP/S web service request, the transport mechanism authenticates the transport-level credentials. If the transport-level credentials were supplied and successfully authenticated, the user associated with the transport-level credentials becomes the effective user. Processing continues to step 3, Message-level authentication. If the transport-level credentials were supplied and are invalid, the transport mechanism rejects the web service request and no further processing occurs. If no transport-level credentials were provided, the effective user is set to Anonymous and processing continues to step 3, Message-level authentication. When Integration Server receives a SOAP/JMS message via a SOAP-JMS trigger, the execution user assigned to the SOAP-JMS trigger becomes the effective user. Processing continues to step 3, Message-level authentication. |
3 | Message-level authentication. If a WS-SecurityPolicy policy is attached to the provider web service descriptor, Integration Server authenticates the message-level credentials. If authentication succeeds, Integration Server extracts the message-level credentials. The user associated with the message-level credentials becomes the effective user. Processing continues with step 4, Authorization check for the provider web service descriptor. If authentication fails for the message-level credentials, Integration Server rejects the request, adds a SOAP fault to the SOAP response, and skips to 8, Response handler services execute. Integration Server will execute the response handler services only if the effective user is authorized to do so. |
4 | Authorization check for the provider web service descriptor. Integration Server determines whether the user is authorized to access the web service descriptor by checking the credentials of the effective user against the execute ACL assigned to the web service descriptor. If access is granted, processing continues with step 5, Authorization check for all handler services. If access is denied, Integration Server adds a SOAP fault to the SOAP response and skips to 8, Response handler services execute. Integration Server will execute the response handler services only if the effective user is authorized to do so. |
5 | Authorization check for all handler services. Integration Server determines whether the user is authorized to access the handler services by performing ACL checking. Integration Server performs ACL checking for a handler service only if the handler service permissions specify that the Enforce execute ACL option is set to Always. Integration Server does not consider handler services to be top-level services. Integration Server uses the credentials of the effective user when performing ACL checking for handler services. If access is denied to any of the handler services, Integration Server processing does not continue. Note:Integration Server performs ACL checking for all request, response, and fault handler service at this point. |
6 | Authorization check for the endpoint service. Integration Server determines whether the user is authorized to access the endpoint service by performing ACL checking. Integration Server performs ACL checking for an endpoint service only when the service permissions specify that the Enforce execute ACL option is set to Always. Integration Server does not consider an endpoint service to be a top-level service. If Integration Server performs ACL checking for the endpoint service, Integration Server uses the credentials of the effective user. If access is granted, processing continues to step7, Endpoint service executes. If access is denied, Integration Server adds a SOAP fault to the SOAP response and skips to step 8, Response handler services execute. Integration Server will execute the response handler services only if the effective user is authorized to do so. |
7 | Endpoint service executes. Integration Server executes the endpoint service. If service execution succeeds, Integration Server converts the response from the endpoint service to a SOAP response and processing continues to step 8, Response handler services execute. If service execution fails, Integration Server converts the failure to a SOAP fault and places it in the SOAP response. Processing continues to step 8, Response handler services execute. |
8 | Response handler services execute. Integration Server takes the SOAP response produced by the endpoint service and begins to execute the response handler services in the handler chain. For more information, see
About Response Handler Services. |
9 | Authorization check for outbound callback service Integration Server determines whether the user is authorized to access the outbound callback service by performing ACL checking. Integration Server performs ACL checking for an outbound callback service only if the service permissions specify that the Enforce execute ACL option is set to Always. Integration Server does not consider outbound callback services to be top-level services. Integration Server uses the credentials of the effective user when performing ACL checking for outbound callback services. If access is denied to the outbound callback service, Integration Server logs an access denied error in the error logs and the processing will continue without interruption. No SOAP fault is added to the SOAP message. |
10 | Outbound callback service executes Integration Server takes the SOAP response message produced by the handler service and begins to execute the outbound callback services in the handler chain. |