Hi Amila, > 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 > ?
Yes absolutely. The new streaming implementation will not be available until next year I guess, and will appear as a new major version (2.0). > 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 ? Apparently yes. There are a lot of questions to be resolved about how we are going to integrate SWSSF with CXF/Rampart/etc, so I would encourage you guys to be involved in the discussions. Colm. On Mon, Aug 22, 2011 at 10:38 AM, Amila Jayasekara <[email protected]> wrote: > 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] >> >> > -- 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]
