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: [Axis2] Proposal - DOM Implementation for Axis2
Date Thu, 19 May 2005 06:10:23 GMT
Eran, all,

see my comments inline pls.

> -----Urspr√ľngliche Nachricht-----
> Von: Eran Chinthaka [mailto:chinthaka@opensource.lk] 
> Gesendet: Donnerstag, 19. Mai 2005 04:38
> An: axis-dev@ws.apache.org
> Betreff: Re: [Axis2] Proposal - DOM Implementation for Axis2
> 
> 
> 
> 
> Hi Werner and all, 
> 
> In addition to my comments on your mail, let me ask some 
> security specific
> questions from you. 
> 
> > 
> > Ruchith, Dims,
> > 
> > first of all: I'm not familiar with the enw Axis 2 OM structure
> > and mechanisms. However, just jumping in here to get a better
> > understanding and the impacts for WS-Security.
> > 
> > What are the impacts of the following quote for the 
> security handlers:
> > 
> > "As long as the OM structure is preserved for the following 
> handlers to
> > work on (e.g: after security), there will be no problems at all."
> 
> I think what he has meant from this statement was that, the 
> handlers after
> security should see the SOAP message, using OM, irrespective 
> of the amount
> of modifications done by the security handler. In other 
> words, security
> handler should output a OM tree.

This could mean that the WS handler needs to convert from DOM
to OM if the DOM implementation is not a wrapper on top of OM
and all modifications done using DOM inherently also modify
the OM tree - that's what I meant with "both trees need to be
in sync".

> 
> > 
> > I like to point out that the security mechanisms need the complete,
> > fully serialized SOAP request (or response) as a DOM XML document to
> > work correctly. 
> 
> Well, OM preserves the full infoset of the SOAP message. 
> That's for sure.
> But let me clarify this from you.
> 
> Do we need to implement *all the methods* in all the 
> interfaces for security
> to work ? If we can ignore the implementation of some of those methods
> (which we need to identify as some of the methods can not be 
> implemented
> using existing DOM api), that's good. 

I cannot speak to the xml-sec library that WSS4J uses under the
hood to do all the XML c14n, Signature, Encryption stuff. WSS4J
itself mainly needs several Document/Element/Node methods and
constants to modify the SOAP XML structure. Certainly WSS4J
does not use all DOM methods. Important is that we obviously need
full namespace support.

> 
> 
> > The security functions then add new elements, modify
> > existing elements, delete/replace exisiting elements of 
> that document.
> > This is not only true for the WSS4J functions but also for the
> > underlying Apache xml-sec library. The security handler 
> then replaces
> > the original SOAP request with the "security enhanced" document. 
> 
> Well any handler can replace the incoming SOAP message with 
> whatever it
> likes. Its not a problem.
> 
> > In addition its is important to know that the security 
> enhanced doc shall
> > not be modified afterwards (e.g. new serialization of the 
> doc) because
> > this may destroy signatures. 
> 
> I have need another clarification on this. The SOAP header 
> blocks containing
> mustUnderstand true *must* be processed and there should be a 
> mechanism to
> check whether all the mustUnderstand Header blocks has been 
> processed or
> not. So some handlers may remove some headers or set a flag 
> in the SOAP
> header block.
> 
> So does what u mentioned above implies that what I explained 
> is not allowed.

This cannot stated in general, it depends on the order of processing
and what will be performed with security. As a rule of thumb the
processing order on the server side should be reversed from client
processing (at least as security processing is concered). Security
cannot sign a header if its not yet in the request, thus security
handler is usually the last one on the client side and the first
one on the server side.

- If security processing was done on the client side the resulting
  SOAP request should not be modified (as a rule of thumb).

- After security processing was done on the server side any handler
  that follows can modify the SOAP request because SIgnatures/encryption
  is already done

Regards,
Werner
> 
> Thanks and Regards,
> Eran Chinthaka
> 
> > The Axis WS handlers use Axis methods
> > to ensure that (or JAX-RPC methods in case of the JAX-RPC handler)
> > 
> > Said all this I'm a little concerned about the above statement. The
> > security handler cannot preserve the OM structuture as far as I can
> > see.
> > 
> > Regards,
> > Werner
> > 
> > > -----Urspr√ľngliche Nachricht-----
> > > Von: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > > Gesendet: Montag, 16. Mai 2005 21:23
> > > An: dims@apache.org
> > > Cc: axis-dev@ws.apache.org
> > > Betreff: Re: [Axis2] Proposal - DOM Implementation for Axis2
> > >
> > >
> > > Hi Dims,
> > >
> > > I think the SAAJ implementation can be used once we finalize the
> > > implementation of few places such as
> > > org.apache.axis.saaj.SOAPDocumentImpl (creation of the new DOM
> > > Elements is missing in here).
> > >
> > > As long as the OM structure is preserved for the 
> following handlers to
> > > work on (e.g: after security), there will be no problems at all.
> > >
> > > With the proposed solution I think we can get away from having two
> > > object strctures (OM and DOM) at the same time. But I 
> think I can try
> > > to go ahead with what is there is in SAAJ impl without much of a
> > > problem :-)
> > >
> > > Thanks,
> > > Ruchith
> > >
> > >
> > > On 5/16/05, Davanum Srinivas <davanum@gmail.com> wrote:
> > > > Ruchith,
> > > >
> > > > Did you consider using the SAAJ stuff which already has dom
> > > interfaces?
> > > >
> > > > -- dims
> > > >
> > > > On 5/16/05, Ruchith Fernando <ruchith.fernando@gmail.com> wrote:
> > > > > Hi All,
> > > > >
> > > > > In implementing WS-Security capabilities on Axis 2.0 we
> > > will have to
> > > > > convert the OM to DOM and provide the complete
> > > SOAPEnvelope as a DOM
> > > > > implementation.
> > > > > The following changes and additions are proposed to the OM
> > > > > implementation to support this.
> > > > >
> > > > > 1.) The org.w3c.dom.* interfaces will be implemented
> > > extending the OM
> > > > > Impls. (org.apache.axis.dom.*)
> > > > > Also there will be an implementation of org.apache.axis.soap.*
> > > > > interfaces extending from the DOMImpls.
> > > (org.apache.axis.dom.soap.*)
> > > > > In this situation we will have to change some of the
> > > method names in
> > > > > the OM interfaces. E.g.: getNextSibling,
> > > getPreviousSibling in OMNode
> > > > >
> > > > > 2.) A DOMSOAPFactory implementing the SOAPFactory will be
> > > introduced
> > > > > to provide the DOM_SOAP impls. to the StAXSOAPModelBuilder
> > > > >
> > > > > 3.) How to switch the builder when the security related
> > > handlers takes over:
> > > > >
> > > > > Since the security handlers depend on the DOM interfaces,
> > > they  cannot
> > > > > work with pure OM instances. They expect DOM impls. So
> > > now there's a
> > > > > need to switch from normal OM factory to DOM factory. 
> Therefore
> > > > > following method is proposed to to handle this.
> > > > >
> > > > > There will be some processing of the SOAPEnvelope before
> > > it reaches
> > > > > the security handlers.
> > > > > And there will be a reference to this partially built
> > > SOAPEnvelope in
> > > > > the MessageContext object. This SOAPEnvelope consists
> > > only of pure OM
> > > > > based elements (org.apache.axis.soap.*). Now we get the
> > > pull parser
> > > > > from the SOAPEvelope we have through the OMStAXWrapper
> > > (This is used
> > > > > to get the pull events from OMElements, 
> irrespectiveof their build
> > > > > state)
> > > > >
> > > > > PullParser pp = 
> messageContext.getSOAPEnvelope().getPullParser()
> > > > > //Returns a pp pointing to the start of the document
> > > > >
> > > > > Then we create a new StAXSOAPModelBuilder passing the
> > > DOMSOAPFactory
> > > > > together with the pull parser returned from the SOAPEnvelope.
> > > > >
> > > > > StAXSOAPModelBuilder builder = new
> > > StAXSOAPModelBuilder(pp, new DOMFactory())
> > > > >
> > > > > At this point the SOAPEnvelope reference in the 
> message context is
> > > > > pointing to the older pure OM based SOAPEnvelope.
> > > > > This will have to reassigned to the new OM+DOM based
> > > SOAPEnvelope, as
> > > > > shown below:
> > > > >
> > > > > messageContext.setEnvelope(builder.getDocumentElement());
> > > // This will
> > > > > set the reference to the new DOMSOAPEnvelopeImpl
> > > > >
> > > > > Therefore to achieve this we need to have remember the
> > > following point
> > > > > as a best practise : DON'T POINT TO THE SOAP ENVELOPE OF
> > > A MESSAGE,
> > > > > JUST POINT TO THE MESSAGE_CONTEXT ONLY.
> > > > >
> > > > > I think this is one of the best use cases which shows the
> > > beauty of
> > > > > the Factory and Builder concept used in Axis2 - OM design :)
> > > > >
> > > > > Thanks,
> > > > > Ruchith
> > > > >
> > > >
> > > > --
> > > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > > >
> > >
> > 
> 
> 
> 

Mime
View raw message