Integration Server 10.7 | Web Services Developer’s Guide | Web Service Authentication and Authorization | Authentication and Authorization for Provider Web Service Descriptors
 
Authentication and Authorization for Provider Web Service Descriptors
Important:
This information only applies to a provider web service descriptor that runs on the web services stack available in Integration Server 8.2 or later (that is, the Pre-8.2 compatibility mode property is set to false). For information about the authentication and authorization process for a provider web service descriptor that runs on the web services implementation introduced in Integration Server versions 7.1, see Authentication and Authorization for Provider Web Service Descriptors on an Earlier Web Services Implementation.
When Integration Server acts as the web service provider, Integration Server authenticates the user when it receives a web service request. Integration Server performs authorization by checking the execute ACL for the provider web service descriptor and, if necessary, for the handler services and endpoint service. Integration Server performs these tasks using the credentials of the effective user. The identity of the effective user begins as Anonymous, but may be supplanted by transport-level credentials or message-level credentials.
Within the context of authentication and authorization for provider web service descriptors, the terms below have the specified definitions:
*Transport-level credentials. The credentials present available with the transport layer. For example, the userid and password in the HTTP headers are considered transport-level credentials.
*Message-level credentials. The use of message-level credentials for authorization purposes is only possible if WS-Security is used with the web service descriptor.
*Effective user. The user identity that is currently being used for purposes of authorization. The effective user identity begins as Anonymous and may be replaced subsequently by a user identity from the transport-level credentials or the message-level credentials.
*Authentication. The act of validating a set of credentials to verify the identity of a user. For example, authentication may involve checking the validity of a provided userid/password combination or checking the validity of an X509 certificate or its expiration. After the user is authenticated, the user identity becomes the “effective user”.
*Authorization. The act of determining whether a given user identity is allowed to access a particular resource.
The table below summarizes the processing points at which Integration Server performs authentication and authorization for a provider web service descriptor.
Note:
You can use WS-SecurityPolicy to secure a web service only when the web service descriptor is running on the running web services stack available in Integration Server 8.2 or later (i.e., the Pre-8.2 compatibility mode property is false). For more information about compatibility mode, see About Pre-8.2 Compatibility Mode.
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.