You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by "Fergusson, Hamish" <Ha...@sabre-holdings.com> on 2004/08/10 23:49:29 UTC
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.
Re: Kinda stuck for a solution here
Posted by Jimmy zhang <cr...@comcast.net>.
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" <Ha...@sabre-holdings.com>
To: <ax...@ws.apache.org>; <ax...@ws.apache.org>
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.
Re: Kinda stuck for a solution here
Posted by Marc Boorshtein <ma...@octetstring.com>.
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 "marc.boorshtein@octetstring.com" on aug 1 and aug 2, pretty
detailed explanation of how to do this.
------------------------------------------------------------------------
--------------------------
Marc Boorshtein
Sr. Software Engineer, Octet String
marc.boorshtein@octetstring.com
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.
>