incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Giger <>
Subject [PROPOSAL] SWSSF (Streaming-WebServices-Security-Framework) for Incubator
Date Tue, 11 Jan 2011 21:22:49 GMT
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


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

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

= 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


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,

Bouncy Castle Licence: Bouncy Castle Provider 

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 -, WSS4J, Web Services Metadata
2.0, Woodstox, XML Commons External Components XML APIs, XML Commons
Resolver Component, XML Security, Xerces2 Java Parser, XmlSchema 




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

== Issue Tracking ==


= Initial Commiters =

  * NAME             EMAIL
  * Marc Giger       gigerstyle at gmx dot ch

= Sponsors =

== Champion ==


== Nominated Mentors ==


== Sponsoring Entity ==


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message