>thus security handler is usually the last one on the client side and the first >one on the server side.
Elaborating further: security handler is usually last one in the request flow and first one in the response flow on client side and first one in the request flow and the last one in the response flow on the server side -----Original Message----- From: Dittmann Werner [mailto:[EMAIL PROTECTED] Sent: Thursday, May 19, 2005 1:10 AM To: '[email protected]' Subject: AW: [Axis2] Proposal - DOM Implementation for Axis2 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/ > > > > > > > > > > > >
