Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Kinda stuck for a solution here
Date: Tue, 10 Aug 2004 16:49:29 -0500
Message-ID: 
 <8A1F9FA924FBDB47A53086AA86BBDDA310CF2A@sgtulmsp03.global.ad.sabre.com>
Thread-Topic: Kinda stuck for a solution here
Thread-Index: AcR/I/uVGKvfhgDEQfGnVva3wHvfWQ==
From: "Fergusson, Hamish" <Hamish.Fergusson@sabre-holdings.com>
To: <axis-user@ws.apache.org>,
	<axis-dev@ws.apache.org>

Hello All,=20

I was wondering if any of you had any suggestions regarding a problem =
myself and the rest of our development=20
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=20
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=20
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=20
then back to the client.  That would have been ideal, BUT the security =
server/router will not handle SOAPFaults ( this is=20
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=20
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=20
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,=20


Hamish.