Hi Marc/Colm, I am sorry, if i am hijacking your mail thread. But thought of using the same thread as my questions are relevant to SWSSF integration.
We are in the process of porting Rampart code to use WSS4J 1.6.2. We are hoping to contribute relevant changes to Apache Rampart within next 2 weeks. We are also interested in using streaming ability within Rampart. But as far as i know Rampart already have policy processing and policy verification code. So i am having following questions with this regard, 1. After this change will we be able to use WSS4J as we do it now, (As in current release, i.e 1.6.2) without doing major changes to Rampart ? 2. Is it possible to disable policy processing within SWSSF so that we can use streaming ability on messages and use policy processing already within Rampart ? Thanks in advance. AmilaJ On Mon, Aug 22, 2011 at 2:29 PM, 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? > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
