axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dittmann Werner <werner.dittm...@siemens.com>
Subject AW: AW: WSS4J - WS-Security Implementation (was Re: axis-wsse)
Date Mon, 27 Oct 2003 15:24:27 GMT
Dims,

about previous Axis releases: did'nt checked that, but I believe
that it would be possible if the small patch to SOAPPart is applied.
The other Axis dependencies are IMO not specific to Axis release
(maybe 1.0 may not work).

Currently the dependency of WSS4J on Axis is not too big. Obviously
the handlers are Axis specific. The handlers are responsible of
the message handling and therefore depend on the JAXRPC
implementation. 

With some care during the development the WSS4J toolkit can be
kept independent of Axis. There could be JAXRPC implementation
specific classes that connect to the WSS4J (for Axis these classes
would be the handlers) 

Currently Axis dependencies are found in:

- AxisUtil.java (here another JAXRPC needs
  to supply its utitls, maybe the existing ones can serve
  as template). Should be easy.

- WSSecurityUtil.java - dependy on axis.MessageElement and
  Axis XMLUtils. IMHO should be easy for other JAXRPCs to
  replace.

- WSSecurityEngine.java - depends on AxisFault, IMO this should be
  change to a WS security fault anyhow.

- token/BinarySecurity.java, UsernameToken.java - depend on 
  Axis XMLUtils and Axis encoding of Base64

- token/Reference.java, SecurityTokenReference.java - depend on 
  Axis XMLUtils

I believe most of these dependencies could be removed with not too
much effort.

The other parts do not import or use Axis specific classes.
Of course they use Apache classes, e.g. for logging, etc. but
this is not a dependency on Axis.

Regards,
Werner

> -----Urspr√ľngliche Nachricht-----
> Von: Davanum Srinivas [mailto:dims@yahoo.com] 
> Gesendet: Montag, 27. Oktober 2003 15:23
> An: axis-dev@ws.apache.org
> Betreff: Re: AW: WSS4J - WS-Security Implementation (was Re: 
> axis-wsse)
> 
> 
> Werner,
> 
> This is good stuff. Yes, there are optimizations, refactoring 
> etc that can be done. One question
> am debating is should the WSS4J work with already released 
> version of Axis? Should we minimize
> dependency on Axis such that people can use WSS4J with other 
> JAXRPC impl's? At this point am not
> sure about this. What are your thoughts?
> 
> Thanks,
> dims
> 
> --- Dittmann Werner <werner.dittmann@siemens.com> 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 
> WSEnvelopeBuilder.build() 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/SOAPPart.java 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 SOAPPart.java 
> and the two
> > modifed files WSSecuritySigningHandler.java and
> > WSEnvelopeBuilder.java. 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 [mailto:dims@yahoo.com] 
> > > Gesendet: Mittwoch, 22. Oktober 2003 13:49
> > > An: axis-dev@ws.apache.org
> > > 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 - http://webservices.apache.org/~dims/
> > > 
> > 
> > 
> 
> > ATTACHMENT part 2 application/zip name=wss4j-1.zip
> 
> 
> 
> =====
> Davanum Srinivas - http://webservices.apache.org/~dims/
> 

Mime
View raw message