If the router doesn't handle SOAP fault info from the security logic, then the router must embed teh security logic and perform security checking itself.
For the other, why don't you probably want to use some other XML parser that allows message modification. In case performance is important, I recommend that you look at vtd-xml. It is a high performance XML parser that allows for incremental update. http://vtd-xml.sf.net ----- Original Message ----- From: "Fergusson, Hamish" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, August 10, 2004 2:49 PM Subject: Kinda stuck for a solution here 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. Thanks, Hamish.
