If you have a set structure you can create the xml (either by creating a DOM by hand or creating a string with the xml and parsing). Then you add it to the response message. Look through the archives for stuff from me "[EMAIL PROTECTED]" on aug 1 and aug 2, pretty detailed explanation of how to do this.




------------------------------------------------------------------------ --------------------------
Marc Boorshtein
Sr. Software Engineer, Octet String
[EMAIL PROTECTED]
On Aug 10, 2004, at 4:49 PM, Fergusson, Hamish wrote:


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.




Reply via email to