Friday, June 13, 2008

CXF vs OC4J ... Round 2

Security is a big deal in our deployment environment and one thing being used is all HTTPS connections require Mutual Authentication. This past sprint, one story I worked on involved reproducing the mutual authentication requirement on a mock service implementation in our local test environments (so we're as close as possible to the real deal). This is the same service I talked about last time; one that we're using CXF to create a mock implementation of and client for, from the provided WSDL.

I began by enabling server authentication only, which went well and took no time at all. However, enabling the client authentication threw a huge wrench into the mix. Seriously, the stars had to align to hit us with this one.

The error: Attempting to invoke the service returns a 405 Method Not Allowed and your Apache error log shows SSL Re-negotiation in conjunction with POST method not supported

  • Condition 1: The service you're hitting requires client authentication via an SSL Certificate

  • Condition 2: When using the CXF Client, you point it at the live WSDL
    • When generating client code from a WSDL, by default, the client's default constructor will use the path on the file system to the WSDL; alternatively, another constructor takes the WSDL location as a parameter
    • Details here

  • Condition 3: The service is invoked through Apache; a version lower than 2.2.0.
    • A common setup is Oracle Application Server with Oracle HTTP Server (Apache)

  • Condition 4: You're not in control of the box where the service is deployed

Basically, CXF is initializing the connection with a GET request to retrieve the WSDL. Following this GET, CXF makes a POST request to invoke the service. Switching from a GET to a POST is causing the error. We thought for a minute that if necessary, we could copy the WSDL to the file system (WEB-INF/wsdl/ maybe?) and therefore, CXF wouldn't perform the GET. Then we realized, when CXF parses the WSDL, it retrieves any imports it finds. If one of those is a resource (custom XSD for example), it must perform a GET to retrieve that from the server.... leaving you right back at square one.

We temporarily abandoned our effort here. We need to be 100% sure that the Oracle HTTP Server in our deployment environment hasn't been patched. We'll approach the group that owns the service we're integrating with and see what their thoughts are and whether or not they've had the same issue (this service is still in development). Hopefully we can resolve this w/o moving WSDLs and XSDs to the file system and creating a maintenance nightmare.


1 comment:

TY said...


This looks like an older post so I'm wondering what you ended up doing in your predicament... Which sounds quite similar to the one we're in right now.