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. 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 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. 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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
