Integration Server 10.7 | Web Services Developer’s Guide | Web Service Authentication and Authorization | Authentication and Authorization for Consumer Web Service Descriptors While Processing Asynchronous Responses
 
Authentication and Authorization for Consumer Web Service Descriptors While Processing Asynchronous Responses
Important:
This information only applies to a consumer web service descriptor that is created on Integration Server 9.0 or later and has the Pre-8.2 compatibility mode property set to false.
The table below summarizes the processing points at which Integration Server performs authentication and authorization for a consumer web service descriptor while processing asynchronous responses.
Step
Description
1
Port access verification
When Integration Server receives an inbound web service response through an HTTP/S port, Integration Server verifies that the consumer web service descriptor can be invoked through that port.
*If access to the consumer web service descriptor is allowed through the port, Integration Server proceeds to step 2, Transport-level authentication.
*If access to the consumer 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 response received via the JMS transport.
2
Transport-level authentication.
When Integration Server receives an HTTP/S web service response, 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 response 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 consumer 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 response.
4
Authorization check for the consumer 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 response and fault handler services.
*If access is denied, processing skips to step 7.
5
Authorization check for response and fault handler services.
Integration Server determines whether the user is authorized to access the response and fault handler services by performing ACL checking. Integration Server performs ACL checking for a response handler service only if the response handler service permissions specify that the Enforce execute ACL option is set to Always. Integration Server does not consider response handler services to be top-level services.
Integration Server uses the credentials of the effective user when performing ACL checking for response handler services.
If access is denied to any of the response handler services, Integration Server processing does not continue.
Note:Integration Server performs ACL checking for all response and fault handler services at this point.
6
Authorization check and execution of the response service.
Integration Server determines whether the user is authorized to access the response service by performing ACL checking.
Integration Server performs ACL checking for a response service only when the service permissions specify that the Enforce execute ACL option is set to Always. Integration Server does not consider a response service to be a top-level service.
If Integration Server performs ACL checking for the response service, Integration Server uses the credentials of the effective user.
*If access is granted, response service executes.
*If access is denied, processing skips to step 7, Response handler services execute. Integration Server will execute the response handler services only if the effective user is authorized to do so.
7
Response handler services execute.
Integration Server invokes the genericFault_Response service if the user is authorized to access it. If user is denied access to the generic_FaultResponse service, Integration Server logs an error.