Hi Colm, On Mon, 22 Aug 2011 09:59:39 +0100 Colm O hEigeartaigh <[email protected]> wrote:
> Hi Marc, > > One thing I would like to discuss is that we move the streaming c14n, > signature and encryption code to the Santuario project. It seems like > the logical place for it, rather than keep it as part of WSS4J. There > is a large number of test vectors in Santuario that we could test the > streaming code against, etc. What do you think? Would it be possible > to easily isolate this code in SWSSF? What external dependencies would > it have? Before I began to develop swssf I was studing the source code of WSS4J and santuario in detail. During this time I came to the conclusion that just small pieces of the code can be reused. When you e.g. move the encryption code to santuario you also have to move the ProcessorChainImpl. And if you move the ProcessorChainImpl you have to move most of the framework. When you just move e.g. the encryption/decryption code it will become useless. Let me explain this in the case of signature verification (encryption/decryption is a lot more complex): The signature verification needs a - Signature-Header processor - A signedInfo processor - C14N feeder - buffer and replay processor for the header, to catch signed header elements (use before declaration) All these components must be applied at the right time and in the right order. This is one of the ProcessorChainImpl responsiblities. Set the InputProcessorChainImpl logging to debug, run the test-cases and you will see the processor interactions. Another important dependency are the SecurityEvents. They will be emitted in realtime when a security-relevant event occurs. Have a look into the SecurityEvent class. Other than that, most of the tests in xml-sec are incompatible because of different structures or just because the dependency to DOM. Left are just the C14N tests which I have ported over to swssf. Summary: What we could do is to move all of the code to santuario and just left WSS specific things in WSS4J like - SAMLTokenProcessors - Timestamprocessors - UsernameProcessors - PolicyProcessors - ... and all of the direct dependencies. So it is doable but no easily. I think such a split up will lower the maintainability. Another way to go is just to cleanly integrate swssf into WSS4J and wait until one requests the streaming ability in xmlsec. Then we have a use case and we can think about it, then generic xmlsec is a bit more complicated than WSSec. <loudlyThinking>Why not merge WSS4J and santuario? :-)</loudlyThinking> Don't hesitate to ask more questions. Also I can draw concept/architecture diagramms if it helps to understand the framework. Kind regards Marc > > Colm. > > On Thu, Aug 18, 2011 at 8:06 PM, Marc Giger <[email protected]> wrote: > > Hi Colm, > > > > On Thu, 18 Aug 2011 15:18:02 +0100 > > Colm O hEigeartaigh <[email protected]> wrote: > > > >> Hi Marc, > >> > >> > So what do you think? Are you interested in it? > >> > >> Absolutely :-) > > > > Cool :-) > > > >> > >> WSS4J currently has two branches, 1.5.x (current release 1.5.12) that > >> is essentially deprecated but still maintained for bug-fixes (and used > >> by Rampart), and trunk (current release 1.6.2) which involved the > >> Opensaml2 update. Once I finish the Kerberos support trunk will be > >> more or less feature complete I think. > >> > >> I think we could use your project as the basis for a WSS4J 2.0 release > >> next year. You would need to submit the code under an Apache License, > >> and we could subsequently grant you commit rights for the project. > > > > Sounds good to me. > > > >> > >> I think the code as is would likely need quite a lot of work, but we > >> would start by just dumping the code in svn and discussing what needs > >> to be done with it etc. For example, your project is coupled with > >> WS-SecurityPolicy support which WSS4J does not currently do, so we > >> could discuss whether it should stay like this, or whether we could > >> separate it out into a separate module etc. > > > > Yes, at first glance it seems like the WS-SecurityPolicy is hard coupled > > with the rest. But this not the case. WS-SecurityPolicy is very loosely > > coupled. All what you have to do when you want policy verification is > > to add the PolicyProcessor to the chain and registering of the > > PolicyEnforcer. That's it. The loose coupling was one of my primary > > goals. Moving WS-SecurityPolicy into a separate module is done in 5, > > ok, say in 10 minutes:-) > > Complete separation from swssf doesn't make sense to me, because the > > policy verification is optimized for streaming processing (fail-fast > > behavior) > > > >> > >> How many cases does it actually create a DOM tree - just for SAML > >> creation/processing? > > > > Yes and in the PolicyEnforcerFactory to parse and validate the WSDL and > > its policy. > > > >> > >> I took a quick look at the source-code - I couldn't compile the latest > >> snapshot code, it looks like it is not compiling the schemas by > >> default? > > > > Unfortunately not all files have made it into the tar. A fixed tarball > > is ready to be downloaded. > > Probably you have to lower the heap settings in the pom before you > > execute maven. > > > >> > >> What do you think? > > > > Fine. > > Some questions: > > - In which format do you expect the source? tar? svn dump? Access > > to my repo? ...? > > - Is anything else to do from my side (separating, ...), aside > > re-licensing under the apache license? > > - Whom should I send the (of course re-licensed) code? > > > > Do you have some more questions? > > > > Kind regards > > > > Marc > > > > > > > >> > >> Colm. > >> > >> > >> > >> > >> On Tue, Aug 16, 2011 at 11:56 AM, Marc Giger <[email protected]> > >> wrote: > >> > Hello All > >> > > >> > Back in january i wrote an email > >> > (http://mail-archives.apache.org/mod_mbox/incubator-general/201101.mbox/%[email protected]%3E) > >> > to the incubator mailing list to discuss the inclusion of > >> > swssf as a new incubator project. The feedback was positive but > >> > the people suggested as alternative way the inclusion into WSS4J. > >> > > >> > So here I am again:-) > >> > > >> > It would be a pity when all of the code fizzles out. > >> > Details to the project and the code can be found on > >> > http://gigerstyle.homelinux.com/?page_id=76 > >> > > >> > If you find the code or parts of it useful, I'm willing to > >> > re-license it under the Apache License. > >> > > >> > It is not my intention to leave the code the ASF and forget > >> > about it. Further development from my side is guaranteed. > >> > > >> > So what do you think? Are you interested in it? > >> > One of the open discussion points will be the integration: Should / > >> > Can it be integrated as it is or must be done some adaptions? > >> > Or probably you don't like the concept? Tell me please! > >> > > >> > Thank you. > >> > > >> > Kind regards > >> > > >> > Marc > >> > > >> > -- > >> > Lesson 1: Cryptographic protocols should not be developed by a > >> > committee. -- Niels Ferguson and Bruce Schneier -- > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > > >> > >> > >> > >> -- > >> Colm O hEigeartaigh > >> > >> http://coheigea.blogspot.com/ > >> Talend - http://www.talend.com > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > > > -- > > Lesson 1: Cryptographic protocols should not be developed by a > > committee. -- Niels Ferguson and Bruce Schneier -- > > > > > > -- > Colm O hEigeartaigh > > http://coheigea.blogspot.com/ > Talend - http://www.talend.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- itServe AG M.Sc. Marc Giger Länggassstrasse 26 3000 Bern 9 Tel.: +41 31 305 16 16 Fax: +41 31 305 16 17 Direkt: +41 31 305 43 27 Email: [email protected] http://www.itserve.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
