Eran, all, see my comments inline pls.
> -----Urspr�ngliche Nachricht----- > Von: Eran Chinthaka [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 19. Mai 2005 04:38 > An: [email protected] > 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:[EMAIL PROTECTED] > > > Gesendet: Montag, 16. Mai 2005 21:23 > > > An: [EMAIL PROTECTED] > > > Cc: [email protected] > > > 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 <[EMAIL PROTECTED]> wrote: > > > > Ruchith, > > > > > > > > Did you consider using the SAAJ stuff which already has dom > > > interfaces? > > > > > > > > -- dims > > > > > > > > On 5/16/05, Ruchith Fernando <[EMAIL PROTECTED]> 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/ > > > > > > > > > > > >
