Integration Server 10.3 | Web Services Developer’s Guide | Web Service Authentication and Authorization | Authentication and Authorization for Provider Web Service Descriptors on an Earlier Web Services Stack
 
Authentication and Authorization for Provider Web Service Descriptors on an Earlier Web Services Stack
Important:
This section summarizes the authentication and authorization process for a provider web service descriptor that runs on the web services stack available in Integration Server versions 7.x, 8.0, and 8.0 SP1(that is, the Pre-8.2 compatibility mode property is set to true). For information about the authentication and authorization process for a 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), see Authentication and Authorization for Provider Web Service Descriptors.
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 within 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.
Note:
You can use the WS-Security handlers to secure a web service only when the web service descriptor is running in pre-8.2 compatibility mode (i.e., the Pre-8.2 compatibility mode property is true). 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 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 Controlling Access to Resources by Port.
2
Transport-level authentication.
When Integration Server receives an inbound 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, Authorization check for all handler services.
*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, Authorization check for all handler services.
3
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.
4
Request handler services execute.
Integration Server takes the SOAP request from the consumer and executes the request handler services in the handler chain. For more information, see About Request Handler Services.
If WS-Security is not in use for the provider web service descriptor, processing continues with step 5, Authorization check for the provider Web service descriptor.
If WS-Security is in use for 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 5, Authorization check for the provider web service descriptor.
*If authentication fails for the message-level credentials, Integration Server rejects the request and processing skips to step 7, Response handler services execute.
5
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 6, Authorization check for the endpoint service.
*If access is denied, Integration Server adds a SOAPFault to the SOAP response and skips to 8, Response handler services execute.
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 step 7, 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.
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 and begins to execute the outbound callback services.