axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fergusson, Hamish" <>
Subject Kinda stuck for a solution here
Date Tue, 10 Aug 2004 21:49:29 GMT
Hello All, 

I was wondering if any of you had any suggestions regarding a problem myself and the rest
of our development 
team are facing:

1) Our application consists of a security server/router ( owned by a third party ) that authenticates
users  of our web service.
This security server accepts SOAPMessages , does some authentication and adds some attributes
to the SOAPHeader and forwards 
that SOAPEnvelope to my web service.

2)  I need to do some additional security that uses the attributes the security  server/router
added to the SOAPHeader.
These are only visible at the handler level, as the header does not appear in my WSDL.

3)  In a request handler, I extract the header info from the SOAPMessage and perform my security
code, if it passes, that's 
fine and the SOAPMessage goes to the web service and it's business as usual.

The problem is that what do I do when my security business logic fails?????

Well, I could have created a SOAPFault from my request handler and that would be sent back
to the security server/router and 
then back to the client.  That would have been ideal, BUT the security server/router will
not handle SOAPFaults ( this is 
their policy, we have to have an Error structure within our SOAPBody in our response message
to represent errors/exceptions/faults).
This is crazy, but they won't budge, believe me we fought this battle with them and lost.

Another thing I thought of was:

Again in a request handler, when my security business logic fails, set some attribute in the
SOAPBody to indicate a failure 
condition.  I would check this when the java object was created on the server and return our
custom error struture in the response
object ( remember, not a SOAPFault ).
The problem with this approch is that the Axis classes for setting values in the SOAPBody
are overriden and prevent you
from modifying the message in the SOAPBody.  Currently this would be my prefered approach,
but would mean I would have
modify the AXIS code, which I'm not too keen on doing?

So the heart of the problem I'm facing is that I need a way of identifying that the error
condition that was found on the 
request handler can be identified on the actual code excuted on my web service business logic.

Does anyone out there know how I might accomplish this?

I'd appreciate any feedback.



View raw message