Hi Werner, Axis2 DOES reconstruct the document before handing over to security processing.
See: org.apache.axis2.security.WSDoAllReceiver: Line 121: org.apache.axis2.security.WSDoAllSender: Line 165: Axis2Util.getDocumentFromSOAPEnvelope(msgContext.getEnvelope()); The default behaviour of the Axis2 security module does _not_ optimize the base64 values all the time. the user will have to _specificaly_ configure the sender handler to do so. Therefore right now Scenario #6 runs fine with sending normal XML over the wire. BUT I just tried Scenario #6 with optimizing the CipherValue. and sig verification failed :-). I guess there's a problem in MTOM processing and it must be fixed. Will dig into it now and check. Thanks, Ruchith On 10/24/05, Dittmann, Werner <[EMAIL PROTECTED]> wrote: > Ruchith, > > if Axis2 behaves that way then interop scenario #6 will fail > if Axis2 does not reconstruct the document before it is > handed over the signature verification. What Axis2 does in > this case, it modifes a signed document. > > Regards, > Werner > > > -----Ursprüngliche Nachricht----- > > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > > Gesendet: Montag, 24. Oktober 2005 09:19 > > An: Dittmann, Werner > > Betreff: Re: Picking up resources with a custom classloader > > > > > > Oops missed the attachments again :-( > > > > --Ruchith > > > > On 10/24/05, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > > > Hi Werner, > > > > > > MTOM [1] optimizing changes the message to a MIME message with > > > multiple MIME parts. Usually we optimize the base64 encoded > > content of > > > elements. > > > > > > Please have a look at the two attached messages. (encrypted_msg.txt > > > and MTOM_optimized_encrypted_msg.txt). > > > > > > For example we can optimize the _contents_ of CipherValue > > of a single > > > CipherData element, where we will get a MIME message with two MIME > > > parts. The first part contains the SOAPEnvelope with the contents of > > > the CipherValue element replaced by <xop:Include ...> > > element which as > > > an 'href' attribute referring to the content id of the second MIME > > > part which contains the binary form of the contents of the > > CipherValue > > > element.Even though the XML is modified, this MIME message is read > > > into OM and the OM structure is built precisely at the > > receiving end. > > > And from this OM structure when we try to get the text value of the > > > optimized element we will get the base 64 encoded value just as what > > > is expected. > > > > > > This works well with encryption and it even interoped with > > MSFT !!! :-) [2] > > > I think signature should work, will try it out. > > > > > > Thanks, > > > Ruchith > > > > > > [1] http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/ > > > [2] http://blogs.cocoondev.org/dims/archives/003408.html > > > > > > On 10/24/05, Dittmann, Werner <[EMAIL PROTECTED]> wrote: > > > > Ruchith, > > > > > > > > looks good for me. I'll checkout from SVN soon to have a look > > > > into the handlers. > > > > > > > > BTW, what does "MTOM optimizing" really mean? Does this > > > > optimization modify elements, namespaces, or otherwise > > > > modifies the XML data? If so we should be very careful > > > > because this could result in a failure of SIgnature > > > > verification. > > > > > > > > Regards, > > > > Werner > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > > > > > Gesendet: Sonntag, 23. Oktober 2005 22:41 > > > > > An: [email protected] > > > > > Cc: Dittmann, Werner; [EMAIL PROTECTED] > > > > > Betreff: Re: Picking up resources with a custom classloader > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > I just cleaned up the use of 'repetition' element in > > the out flow > > > > > cofiguration and now Axis2 security module configuration look as > > > > > described in this : > > > > > http://marc.theaimsgroup.com/?l=axis-dev&m=112983906808070&w=2 > > > > > > > > > > This is how the interop scenario 5 configuration looks > > like in Axis2 > > > > > now: (See <parameter name="OutflowSecurity"> element) > > > > > http://svn.apache.org/viewcvs.cgi/*checkout*/webservices/axis2 > > > > > /trunk/java/modules/integration/test-resources/security/s5.cli > > > > > ent.axis2.xml > > > > > > > > > > msgContext.getEnvelope().build() will build the OM (aka AXIOM) > > > > > structure of the envelope element IF it is not built at > > that point, > > > > > due to the deferred built nature of OM. It does not > > serialize the > > > > > envelope but simply completes the XML object model. > > > > > > > > > > In the case when the handler is chained (repeated) (in > > fact whenever > > > > > the handler is called) the OM is completely built just before > > > > > converting OM to DOM. See : > > > > > org.apache.axis2.security.util.Axis2Util.getDocumentFromSOAPEn > > > > > velope(SOAPEnvelope > > > > > env) [1]. In this I had to perform env.build(), since > > > > > evn.serializeAndConsume() does not serialize the > > envelope properly (to > > > > > construct DOM) when it is not completely built. BTW > > > > > evn.serializeAndConsume() used to be env.serialize() [2] until > > > > > recently. > > > > > > > > > > Making the OM structure complete was added to this point in the > > > > > handler code when we introduced MTOM optimizing certain > > portions of > > > > > the message. For example base64 encoded text in the > > CipherData element > > > > > can be MTOM optimized. This was done to make sure that the OM > > > > > structure that is complete before its querried using > > XPath. But, now I > > > > > see that, this shouldn't make a diffrence, since during XPath > > > > > processing the OM structure is built anyway :-). > > Therefore we can > > > > > actually get rid of that line and things should work without a > > > > > problem. > > > > > > > > > > Thanks, > > > > > Ruchith > > > > > > > > > > [1] > > > > > http://svn.apache.org/viewcvs.cgi/webservices/axis2/trunk/java > > > > > /modules/security/src/org/apache/axis2/security/util/Axis2Util > > > > > .java?rev=326985&view=markup > > > > > [2] > > > > > http://svn.apache.org/viewcvs.cgi/webservices/axis2/trunk/java > > > > > /modules/security/src/org/apache/axis2/security/util/Axis2Util > > > > > .java?rev=293501&r1=292217&r2=293501&diff_format=h > > > > > > > > > > On 10/21/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > > > > > Yes, we are gonna clean up that repition thing. Ruchith can > > > > > explain it > > > > > > better. It has to do with Signing twice for example > > > > > > > > > > > > thanks, > > > > > > dims > > > > > > > > > > > > On 10/21/05, Dittmann, Werner > > <[EMAIL PROTECTED]> wrote: > > > > > > > Thanks Dims, Ruchith. > > > > > > > > > > > > > > I just had a look in Axis2 security handler, looks very nice > > > > > > > indeed. Also the parameter structurce looks much nicer > > > > > > > than in Axis1 :-). > > > > > > > > > > > > > > Seems that I need to get maven to get Axis2 up and running > > > > > > > on my system. > > > > > > > > > > > > > > Just one small question: When doing a "repetition" > > > > > > > aka HandlerChaining there is a call to > > > > > > > msgContext.getEnvelope().build() even in the case there > > > > > > > is a repetition and the enevelope may not be ready > > yet. Isn't > > > > > > > that an overhead (I'm not familiar with the way > > Axis2 sets up > > > > > > > it internal structures)? > > > > > > > > > > > > > > Regards, > > > > > > > Werner > > > > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > > > > Von: Davanum Srinivas [mailto:[EMAIL PROTECTED] > > > > > > > > Gesendet: Freitag, 21. Oktober 2005 16:12 > > > > > > > > An: Ruchith Fernando > > > > > > > > Cc: Dittmann, Werner; [email protected] > > > > > > > > Betreff: Re: Picking up resources with a custom > > classloader > > > > > > > > > > > > > > > > > > > > > > > > Werner, > > > > > > > > > > > > > > > > The code is here: > > > > > > > > > > http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/m > > > > > > > > odules/security/ > > > > > > > > > > > > > > > > As you can see it is a VERY THIN layer on top of wss4j. > > > > > just 4 classes > > > > > > > > and some supporting classes. > > > > > > > > > > > > > > > > thanks, > > > > > > > > dims > > > > > > > > > > > > > > > > On 10/21/05, Ruchith Fernando > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi Werner, > > > > > > > > > > > > > > > > > > Please see my comments below: > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Ruchith > > > > > > > > > > > > > > > > > > On 10/21/05, Dittmann, Werner > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > > without having a look into Axis2 I have some > > questions: > > > > > > > > > > > > > > > > > > > > - how many classloader environments does > > Axis2 need/uses? > > > > > > > > > > - what is the difference between "Axis2 > > module classloader" > > > > > > > > > > and "Axis2 service classloader" > > > > > > > > > > > > > > > > > > Axis2 uses two classloaders one for services and one for > > > > > > > > modules. IMHO > > > > > > > > > this is mainly because the Axis2 services and > > modules are > > > > > > > > archived and > > > > > > > > > they are expected to work in isolation. Therefore the > > > > > > > > classloader that > > > > > > > > > is associated with the module archive is the > > 'module class > > > > > > > > loader' and > > > > > > > > > similarly with the service. The third party libs and > > > > > other resources > > > > > > > > > associated with the module or the service will be > > > > > packaged in that > > > > > > > > > respective archive and will only be pickedup by > > the respective > > > > > > > > > classloader. > > > > > > > > > > > > > > > > > > > - does a handler like the WSS4J handler runs as > > > > > Axis2 service > > > > > > > > > > or as Axis2 module? > > > > > > > > > > > > > > > > > > We have ports of the WSdoAll* handlers in a > > Axis2 module. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Werner > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > > > > > > > Von: Ruchith Fernando > > [mailto:[EMAIL PROTECTED] > > > > > > > > > > > Gesendet: Freitag, 21. Oktober 2005 14:58 > > > > > > > > > > > An: [email protected] > > > > > > > > > > > Betreff: Picking up resources with a custom > > classloader > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > > > Dims made some changes recently to enable > > WSS4J to load > > > > > > > > the password > > > > > > > > > > > callback class from a given class loader. > > This allowed > > > > > > > > Axis2 security > > > > > > > > > > > module (which is a port of the WSDoAll* > > handlers) to be > > > > > > > > able to load > > > > > > > > > > > the password callback parameters from the service's > > > > > > > > class loader. > > > > > > > > > > > > > > > > > > > > > > Axis2 services have their own classloader > > and this is > > > > > > > > different from > > > > > > > > > > > the classloader available to the Axis2 module. > > > > > > > > Therefore we need to > > > > > > > > > > > supply the service's classloader to WSS4J to > > > > > pickup the required > > > > > > > > > > > resources and classes. > > > > > > > > > > > > > > > > > > > > > > Therefore we should also be able to load the other > > > > > > > > resources such as > > > > > > > > > > > crypto.propertes with a custom class loader (the > > > > > > > > service's classloader > > > > > > > > > > > in the case of Axis2), and we may have to load a > > > > > > > > different Crypto impl > > > > > > > > > > > from the Axis2 service archive. Right now > > this is not > > > > > > > > possible since > > > > > > > > > > > the CryptoFactory and the default Crypto > > impl (Merlin) > > > > > > > > is not capable > > > > > > > > > > > of accessing a custom class loader. > > > > > > > > > > > > > > > > > > > > > > I made some changes and tried it out with > > Axis2 and it > > > > > > > > was able to > > > > > > > > > > > pickup the resources from the Axis2 service archive. > > > > > > > > Please have a > > > > > > > > > > > look at the attached diff. > > > > > > > > > > > > > > > > > > > > > > Can we have this option in WSS4J? Or is > > there a better > > > > > > > > way to do it? > > > > > > > > > > > Thoughts? :-) > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > -- > > > > > > > > > > > Ruchith > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > To unsubscribe, e-mail: > > > > > [EMAIL PROTECTED] > > > > > > > > > > > For additional commands, e-mail: > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Ruchith > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Davanum Srinivas : http://wso2.com/blogs/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Davanum Srinivas : http://wso2.com/blogs/ > > > > > > > > > > > > > > > > > > > > > -- > > > > > Ruchith > > > > > > > > > > > > > > > > > > -- > > > Ruchith > > > > > > > > > -- > > Ruchith > > > -- Ruchith --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
