OSB 11g: HTTP Proxy Services And SSL

I was involved in a Oracle Sevice Bus POC recently and came across some interesting behaviour with respect to how it handles proxy services when accessed via SSL that I was not fully expecting. The proxy services behaved as expected when accessed as intended, i.e. when a proxy service that required SSL was accessed via HTTPS or a proxy service the does not require SSL was accessed via HTTP. The behaviour of interest was when the access method was the opposite of the required scheme.

The following summarizes this behaviour and discusses some options to alter the default behaviour.

SSL Proxy	SSL Request	Expected	Actual	Notes
False	False	200/OK	200/OK	As expected
False	True	200/OK	500/ERROR	Use "WLS-Proxy-SSL=true" HTTP Header to get expected result
True	True	200/OK	200/OK	As expected
True	False	302/Redirect	302/Redirect	The redirect will be to from POST to GET with missing payload!

OSB Proxy Service - HTTP Transport Without SSL

If an OSB proxy service has been configured to use the HTTP transport and has NOT been configured to "Require SSL" (transport configuration option) then attempting to access the proxy service with a client over HTTPS then the OSB will respond with a 500 error response. This is designed behaviour of OSB. It may be a requirement that an OSB proxy service should be accessible over BOTH HTTP and HTTPS. In this case the default behaviour of the OSB proxy service can be altered by setting the HTTP header "WLS-Proxy-SSL" to "true". Setting this header will allow the OSB proxy service to process the message with SSL.


OSB Proxy Service - HTTP With SSL Transport

If an OSB proxy service has been configured to use the HTTP transport and has been configured to "Require SSL" (transport configuration option) then when attempting to access the proxy service with a client over plain HTTP then OSB will respond with a 302 redirect response attempting to redirect the client to the endpoint over the HTTPS scheme. Most HTTP clients if configured to follow redirects will (correctly) follow the POST redirect GET pattern and issue a GET request to the HTTPS endpoint. The request to OSB then does not contain any payload. To protect against this there are two methods which should be considered.

If required a proxy service message pipeline can use the $inbound context variable to retrieve the HTTP method. If the HTTP verb is a GET then the proxy service can raise an error, which in turn will generate a SOAP fault. The HTTP method verb can be accessed by the value of:

$inbound/ctx:transport/ctx:request/http:http-method

The error message returned to the client can then be crafted to indicate to the client that they have attempted to use a method which is not supported and provide a hint that their web service stack may have performed the GET.

Additionally it is good practice to perform validation on the incoming request according to the OSB VETO (validate, enhance, transform, operate) pattern. This validation would fail given a missing message paylod, again by default causing a SOAP fault to be returned to the client. In this case the error message returned to the client would indicate a missing payload which may be somewhat misleading unless the client is aware that they or their web service stack performed the GET.