incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Giger <gigerst...@gmx.ch>
Subject Re: [PROPOSAL] SWSSF (Streaming-WebServices-Security-Framework) for Incubator
Date Fri, 14 Jan 2011 21:26:53 GMT
Hello Dan,

On Wed, 12 Jan 2011 23:24:48 -0500
Daniel Kulp <dkulp@apache.org> wrote:

> 
> Marc,
> 
> I honestly think this would be a VERY hard project to incubate and
> I'd like to suggest an alternative course of action......
> 
> Basically, this is an extremely targetted technology, and not exactly
> a "fun" one at that.   I'm willing to bet I can count the number of
> people in the world that WANT to do WS-SecPol things just on my
> fingers, no toes required. :-)    I think building a community might
> be challenging.

You are right, WS-SecurityPolicy isn't/wasn't that funny, but
Streaming-SOAP-Security is:)

> 
> Colm and I have chatted off and on about similar ideas for a WSS4J
> 2.0 update. Right now, Colm is hard at work on 1.6, but that's mostly
> incremental updates and such, but longer term, we've definitely been
> thinking about how to support a more Stax based streaming for
> WS-Sec.   There were also discussions a while ago about pulling some
> of the policy things from CXF into WSS4J (required a Neethi 3 version
> as well) that I never really had the time to pursue.   Thus, it
> really is inline with some of the thoughts we've had.    Thus, my

I share exactly the same opinion. The experience while implementing the
streaming-based solution showed that a higher integration of
WS-SecurityPolicy into WS-Security makes sense. Regardless, a too high
integration îs also not good, because WS-SecurityPolicy covers more than
just Message-Level protection as you know best. In my design there is a
loose coupling between WS-SecurityPolicy and WS-Security.

> suggestion would be to approach the WSS4J community and spark
> discussions there and possibly use what you have as a starting point
> toward the WSS4J 2.0 ideas.    
> 
> I'm not saying incubating this project is impossible.  I just think
> it would be fairly hard and it might be easier and more enjoyable to
> work with the existing projects.
> 
> That said, if you feel incubation is still the best option, I'd be
> happy to be a mentor, but I'm not sure if I'd have much time to
> contribute beyond mentor duties. 

At the beginning, I've considered a integration into WSS4J/Santuario,
but came to the conclusion that the streaming- and DOM- based
implementations do have totally different requirements.
Nevertheless I'm open for your suggestion and will present my
streaming-based solution on the WSS4J mailing-list to start
a discussion.

Thanks Dan!

Best Regards

Marc


> 
> Dan
> 
> 
> On Tuesday 11 January 2011 4:22:49 pm Marc Giger wrote:
> > Hello All
> > 
> > I would like to formally propose that the SWSSF Project will be
> > considered for inclusion in the ASF Incubator as a new podling. The
> > name of the project is not fixed and I am open for proposals. An
> > idea for a name was "RoadRunner" but this smells like trouble.
> > Please read further for a detailed description what the project is.
> > 
> > Now I am looking for Mentors, contributors and other important
> > person to get the project accepted in the Incubator.
> > 
> > I gracefully ask the Incubator PMC for sponsoring this project.
> > 
> > Feedbacks about the project and the proposal would be appreciated.
> > 
> > Best Regards
> > 
> > Marc
> > 
> > 
> > == Abstract ==
> > 
> > SWSSF (Streaming-WebServices-Security-Framework) is a
> > streaming-based SOAP-Message-Security +
> > WS-SecurityPolicy implementation
> > 
> > 
> > == Proposal ==
> > 
> > SWSSF provides a streaming-based solution for SOAP-Message-Security
> > and WS-SecurityPolicy-Verification. Inbound- and Outbound-Security
> > is supported and based on the StAX API.
> > 
> > 
> > == Background ==
> > 
> > Some Parts of SWSSF were developed within my Master Thesis and
> > implements the SOAP-Message-Security Standard for message integrity,
> > message authentication and message confidentiality . Additionally a
> > Policy verification framework was build to get a "fail-fast"
> > behavior when a policy is violated.
> > 
> > 
> > == Rationale ==
> > 
> > Typically, it will be used a DOM based approach to do the
> > SOAP-Message-Security stuff in WebService-Frameworks as it
> > is done in Apache Axis and Apache CXF. Apache WSS4J and the
> > underlying Apache Santuario are the concrete implementation for
> > WS-Security and uses DOM.
> > Security-processing with DOM yields to multiple problems:
> > - High memory usage
> > - Long processing time
> > - Vulnerable to DoS Attacks
> > - Wasted computer resources in case of a security error.
> > 
> > In contrast, the streaming-based approach of WS-Security shows
> > following characteristic:
> > - constant low memory usage (~5 - 15MB) independent of the document
> > size for inbound messages
> > - factor n less memory consumption on outgoing messages
> > - faster processing time (2 - 3 times faster)
> > - Vulnerability to DoS Attacks mitigated
> > - Minimum a computer resources are wasted in case of a security
> > error due to the possible fail-fast behavior in the streaming
> > environment.
> > - in lot of cases a fail-fast behavior can be guaranteed by policy
> >   violations.
> > 
> > 
> > == Initial Goals ==
> > 
> > SWSSF was a one man show - me. A goal would be to bring the
> > framework, with the help of experienced developers, in a
> > architectural good shape to have a good starting point for further
> > development.
> > 
> > 
> > = Current Status =
> > 
> > Currently SWSSF consists of about 200 Java-Classes
> > with ~18000 lines of codes and ~3800 lines test-code.
> > 
> > Most of the features of WSS4J are implemented.
> > Some refactoring is needed and more time has
> > to be investigated to circumvent limitations in the streaming
> > approach.
> > 
> > 
> > == Meritocracy ==
> > 
> > As already mentioned, SWSSF was developed by me. Experience to
> > work together with a community is limited to provided patches
> > to different Apache and other Projects in the community.
> > 
> > 
> > == Community ==
> > 
> > There exists no community around SWSSF yet.
> > 
> > 
> > == Core Developers ==
> > 
> > SWSSF was developed by me - Marc Giger
> > 
> > 
> > == Alignment ==
> > 
> > I think the project is for further development in good hands by the
> > ASF. Apache WSS4J and Apache Santuario are two examples which are
> > well known , successfully and have the same project goal as SWSS.
> > 
> > 
> > = Known Risks =
> > 
> > == Orphaned products ==
> > 
> > Due to its small number of committers, there is a risk of being
> > orphaned. In my opinion the interest in this project can
> > fast grow, since it solves an long outstanding problem when
> > processing large SOAP documents.
> > 
> > 
> > == Inexperience with Open Source ==
> > 
> > Since I work daily on Open-Source platforms and with
> > Open-Source projects, I have some impressions how the
> > process works. I often open tickets and provide patches.
> > 
> > 
> > == Reliance on Salaried Developers ==
> > 
> > As already mentioned, SWSSF were developed within my Master Thesis.
> > So no company and the like is involved. The code is owned by me.
> > 
> > 
> > == Relationships with Other Apache Products ==
> > 
> > SWSSF compete with Apache WSS4J.
> > A possible integration (already realized) in Apache CXF.
> > A further integration should be possible in Apache Axis2
> > 
> > 
> > == An Excessive Fascination with the Apache Brand ==
> > 
> > I believe that the project is interesting and useful and
> > could be a improvement for existing Apache Projects like
> > Apache CXF and Apache Axis2
> > The Apache Brand may help attract more contributors to
> > improve the project.
> > 
> > 
> > = Documentation =
> > 
> > Documentation exists as Master-Thesis (only in German and which
> > must be clarified with the University if I am allowed to release
> > it). Java-Doc exists to some extent.
> > 
> > 
> > = Initial Source =
> > 
> > Most of the code for SWSSF is written by me. Some source code
> > where lend and extended from Apache Rampart, Apache WSS4J and Apache
> > Santuario.
> > 
> > 
> > = Source and Intellectual Property Submission Plan =
> > 
> > The university confirmed that the code is owned by me and
> > so I can do whatever I want with it. At the moment the
> > code is licensed under LGPL3 for different reasons.
> > If the project will accepted by Apache I have no problem
> > to re-license the code under the ASL
> > 
> > 
> > = External Dependencies =
> > 
> > Most of the following dependencies are needed for
> > test code and integration testing.
> > 
> > Public Domain: AOP alliance
> > 
> > GNU LESSER GENERAL PUBLIC LICENSE: BeanShell
> > 
> > Eclipse Public License - Version 1.0: Jetty Server, Jetty Utilities
> > 
> > Unknown: ASM Core, Java API for XML Based RPC, SLF4J API Module,
> > Streaming-WebService-Security-Framework, Unnamed -
> > com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.2, Unnamed -
> > javax.xml.bind:jaxb-api:jar:2.1, Unnamed -
> > xalan:serializer:jar:2.7.1-mgi, Unnamed - xalan:xalan:jar:2.7.1-mgi,
> > jaxen
> > 
> > Bouncy Castle Licence: Bouncy Castle Provider
> > 
> > Apache License, Version 2.0: TestNG COMMON DEVELOPMENT AND
> > DISTRIBUTION LICENSE (CDDL) Version 1.0: SOAP with Attachments API
> > Package The Apache Software License, Version 2.0: Activation 1.1,
> > Annotation 1.0, Apache CXF API, Apache CXF Command Line Tools
> > Common, Apache CXF Common Schemas, Apache CXF Common Utilities,
> > Apache CXF Runtime Core, Apache CXF Runtime HTTP Jetty Transport,
> > Apache CXF Runtime HTTP Transport, Apache CXF Runtime JAX-WS
> > Frontend, Apache CXF Runtime JAXB DataBinding, Apache CXF Runtime
> > SOAP Binding, Apache CXF Runtime Simple Frontend, Apache CXF
> > Runtime WS Addressing, Apache CXF Runtime WS Security, Apache CXF
> > Runtime XML Binding, Apache Geronimo JAX-WS 2.1 API, Axiom API,
> > Axiom Impl, Commons Codec, Commons Lang, Commons Logging,
> > JCommander, JavaMail 1.4, Log4j, Neethi, Servlet 2.5, Spring
> > Framework: Beans, Spring Framework: Context, Spring Framework:
> > Core, Spring Framework: Web, StAX API, Streaming API for XML (STAX
> > API 1.0), Unnamed - com.google.inject:guice:jar:2.0, WSS4J, Web
> > Services Metadata 2.0, Woodstox, XML Commons External Components
> > XML APIs, XML Commons Resolver Component, XML Security, Xerces2
> > Java Parser, XmlSchema
> > 
> > CPL: WSDL4J
> > 
> > CDDL 1.0: JAXB RI
> > 
> > GPL2 w/ CPE: JAXB RI
> > 
> > Apache Software License - Version 2.0: Jetty Server, Jetty Utilities
> > Common Public License Version 1.0: JUnit
> > 
> > 
> > = Cryptography =
> > 
> > Yes, SWSSF depends strongly on cryptography.
> > 
> > 
> > = Required Resources =
> > 
> > == Mailing lists ==
> > 
> > The following mailing lists will be required:
> > 
> >   * swssf-private
> >   * swssf-dev
> >   * swssf-commits
> >   * swssf-users
> > 
> > == Subversion Directory ==
> > 
> > https://svn.apache.org/repos/asf/incubator/swssf
> > 
> > == Issue Tracking ==
> > 
> > JIRA SWSSF (SWSSF)
> > 
> > = Initial Commiters =
> > 
> >   * NAME             EMAIL
> >   * Marc Giger       gigerstyle at gmx dot ch
> > 
> > 
> > = Sponsors =
> > 
> > == Champion ==
> > 
> >   ??
> > 
> > == Nominated Mentors ==
> > 
> >   ??
> > 
> > == Sponsoring Entity ==
> > 
> >   ??
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> 
> -- 
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message