axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sunil Iyengar <>
Subject Re: AW: WSS4J - WS-Security Implementation (was Re: axis-wsse)
Date Tue, 09 Dec 2003 17:53:11 GMT
Hi Dittmar and axis folks,

Thanks for the pretty good analysis of the serialisation of axis. I have a
question which maybe you guys can answer.
I am using axis1.1 which ships with the ettk toolkit.
I have web services which send and receive simple types (string) and I have a
web service which return or send complex types.
They both work okay and everything is fine using bean serialisers/deserialsers
(default of axis) for the complex case, when there are no security handlers.

When I use handlers at both the client and server for the simple web service
everything works fine, but when I use it with complex types there are lots of
errors like no desrialiser found for child element, typemapping error on the
client side and so on.

I have a feeling its a serialisation issue and wondering how I could apply
your patch or is there any new binary release which incorporates your patch.
Any help or insight would be great. BTW I am not using wss4j.jar for
ws-security, but I feel that the issue is in axis.jar and saaj.jar or maybe
jax-rpc.jar. Please correct me if I am wrong.


Dittmann Werner wrote:

> Dims, wss4j folks,
> Here a patche and some complete files I changed to enable the
> signing handler to handle SOAP with Attachments.
> During the analysis how to do it, I got some deeper insights of the
> serialization process of Axis. When doing signing (and encryption) one
> must take the Axis serialization into account. Here are some general
> remarks about my findings:
> - As a general principle the signing (and the encryption) handler must
>   be the last handler in the chain, just before e.g. HTTP sender. The
>   SOAP contents must not be changed by any other handler after they
>   were signed.
> - Usually the Axis serialization takes place just before the whole
>   content is written to the socket (or any other transport).
> - During serialization the serialization handler may change the SOAP
>   content, e.g. insert reference ids for attachments or
>   multirefs. This would invalidate the signing if it was performed
>   before this step.
> - To overcome this problem the signing (and probably the encryption)
>   handler have to force a complete serialization before signing. The
>   best way to do this, is to call "getAsString()" of the SOAPPart (or
>   SOAPEnvelope) of the original request message. This function is
>   implicitly called by AxisUtil.toDocument() that also creates a new,
>   detached SOAP envelope that is completely serialized. The wohle
>   signing (and encyption) process now works on the fully serialized
>   and detached SOAP Envelope.
> After signing this detached SOAP envelope is used to replace the
> original SOAP envelope of the request message. Here we need to perform
> some tricky things:
> After all the signing is done, the calls the
> method AxisUtil.toSOAPMessage() that converts the detached signed SOAP
> enevelope into a axis message and returns this message to the
> WSSecuritySigningHandler. Here the signed SOAP envelope is converted
> into a String. This string replaces the content of the original SOAP
> Part. The real trick here is to replace the original SOAP Part as
> FORM_STRING. Doing so prevents a new serialization pass on the SOAP
> part. HTTPSender can use it directly.
> To enable this I had to modify axis/ to enable access to
> SOAPPart.FORM_STRING and the setCurrentMessage() method.
> Note: I also tried to use to already public method setContent() (see
> commented lines in source) but due to the string reader methods the
> SOAP content was modified somehow and the verification on the server
> failed.
> I only tried siging/verfication at this point (deployed with tomcat
> because of attachment handling).
> The whole stuff also works for plain SOAP messages without
> attachments.
> The attached ZIP containes a patch file for and the two
> modifed files and
> Please note: the security samples that call
> WSEnvelopeBuilder directly do not compile anymore with the changed
> WSEnvelopeBuilder because the build() signature changed.
> Further things to discuss/think about:
> - combine signing/encryption/username token etc. into one handler,
>   controlled by WSDD settings. This would save repeated conversions
>   between string/DOM/SOAP.
> - what comes first? encryption? signing? (need to check WSS
>   specifications here?)
> Regards
> Werner
> > -----Urspr√ľngliche Nachricht-----
> > Von: Davanum Srinivas []
> > Gesendet: Mittwoch, 22. Oktober 2003 13:49
> > An:
> > Betreff: Re: WSS4J - WS-Security Implementation (was Re: axis-wsse)
> >
> >
> > Werner,
> >
> > Please play with the code in cvs under ws-axis/contrib/wss4j
> > there are handlers for signing the
> > soap message via handlers. It'd  be awesome if you can
> > contribute some patches if you see quirks
> > or need new functionality.
> >
> > thanks,
> > dims
> >
> >
> >
> > =====
> > Davanum Srinivas -
> >
>   ------------------------------------------------------------------------
>                   Name:
>    Type: Winword File (application/zip)
>               Encoding: base64

Sunil Iyengar,
Research Fellow, Networks Group,
Centre For Communication And Systems Research(CCSR),
School of Electronics, Computing & Mathematics,
University Of Surrey, Guildford GU2 7XH,
Surrey, England, United Kingdom.
Office: +44 (0)1483 686008

View raw message