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 --

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to