On Thu, Feb 23, 2012 at 4:23 PM, Colm O hEigeartaigh <email@example.com>
This is a proposed work plan for the WSS4J 2.0 release. This release
will incorporate the existing WSS4J 1.6.x code with the swssf branch
donated by Marc Giger. The goal for WSS4J 2.0 is to be a multi-module
maven project which incorporates both DOM and StAX APIs for working
with WS-Security. It will also include a WS-SecurityPolicy model,
along with the means of verifying a request against this model.
I've grouped the work items roughly by section, with the intention of
creating a JIRA for each (sub)task. Most of the tasks are based on a
review of the swssf branch, and are probably not of interest to any
non-WSS4J developers. However, the first section contains some
important open questions that I would like the community to discuss
1) Open questions
- Apache Santuario contains the (DOM)-based XML signature and
encryption code that WSS4J (and many other projects) rely on. The
branch contains a streaming-xml-security module, which essentially
duplicates this functionality using StAX. Should the
streaming-xml-security module stay in WSS4J or should it go to Apache
Santuario as a new sub-project? Should we go one step further and
merge WSS4J into
Santuario altogether? From an Apache POV it may make more sense to
move some or all of WSS4J to Santuario, as development in Santuario is
kind of grinding to
It's quite reasonable to move streaming-xml-security module to Santuario and +1 for that. It doesn't make any sense to move whole WSS4J into Santuario where Santuario provides security standards for XML while WSS4J provides security
standards for Web Services IMO WSS4J already in it's correct home.
- JDK 1.5 support. The swssf branch currently requires JDK 1.6 due to
java.util.Deque and ArrayDeque classes. Is JDK 1.5 support essential
or should we just drop it for the 2.0 release? If it is, I guess we
could implement our own Deque classes.
If it's less pain to go with JDK 1.6 let's target 2.0 release with JDK 1.6.
- The swssf branch currently uses "org.swssf", WSS4J currently uses
"org.apache.ws.security". Does anyone have any suggestions for how we
change the swssf package names?
- Move 1.6.x code into a new module.
- Factor out common code to be used by both implementations. Some
changes to 1.6.x required. The roughly includes:
a) Crypto classes
b) Exception classes
c) SAML code.
d) Common configuration and constants files
e) Caching nonces/Timestamps.
f) Derived key / Secure Conversation code.
3) Streaming XML Security
- Add support & test for GCM algorithms via BouncyCastle.
- Support stronger digests via the ds:DigestMethod child of
xenc:EncryptionMethod. Support the xenc11:MGF Algorithm as documented
in the XML Encryption 1.1 specification.
- Add "secure validation" property. This property is false by
default. When set to true, it enforces the following processing rules
be separately configurable):
a) Limits the number of Transforms per Reference to a maximum of 5.
b) Limits the number of references per Manifest (SignedInfo) to a
maximum of 30.
c) MD5 is not allowed as a SignatureAlgorithm or DigestAlgorithm.
d) Do not allow remote references (currently not supported anyway)
e) Enforce maximum depth of the xml
- Support non-document signature references
- Support decrypting an Embedded EncryptedKey (in EncryptedData).
- Add in ability to sign/verify & encrypt/decrypt in
streaming-xml-security module. Add interop tests as per Santuario.
- Remove default BouncyCastle requirement.
-- Currently required by default. Get rid of JCEProvider (required)
configuration algorithm (currently set to "BC").
-- Some of the encryption tests are failing in streaming-ws-security
with this change (and after changing the code to not use
the provider if it's not specified).
- Crypto refactoring
-- Get rid of CredentialException in DOM code.
-- Need functionality in Crypto in SWSSF to get a private key via a
-- Add support for CRL's.
- Move common SAML code to a new module.
- Move Crypto & SAMLUtil stuff out of SAMLAssertionWrapper. Reconcile
AssertionWrapper & SAMLAssertionWrapper.
- Support for decrypting an EncryptedKey in the Subject of a SAML Assertion.
- Add support for specifying different algs for sign or c14n a SAML Assertion.
- The SAMLCallback in SWSSF contains signing information, whereas it
does not in WSS4J. SAMLParms and SAMLIssuer* will be removed in the
DOM code as part of this work.
- Is there really a need to have a separate Crypto instance to sign
SAML Assertions? Maybe we should just use the signature Crypto
instance for this instead?
5) Streaming WS-Security
- Port BSP enforcer to streaming code.
- Update code to use correct WSPasswordCallback code as per the DOM
code (scrap USERNAME_TOKEN_UNKNOWN).
- Port Kerberos & SPNEGO work
- Support pluggable Validation of received tokens as per DOM code
- Ensure that SecurityEvents let us see what was processed for the
6) Misc stuff
- Disable Cobertura by default
- Set up a parent pom with dependency management.
- Log4j test logging. We should split this config for xmlsec, wss,
etc and set a system property
in the surefire plugin so that it can pick up the right one.
7) Policy code
- Add CXF support for custom Algorithm Suites.
- Add support for (custom) GCM algorithm-suites.
- Add stricter enforcement of required policy elements as added to CXF.
- Check sender-vouches and holder-of-key requirements for SAML tokens.
- Support Kerberos token policy validation.
- Support IssuedToken policy validation - e.g. checking holder-of-key
requirements as well as the RSTT policy.
- Support Derived Keys policy validation
- Does the policy validation code support checking the token
requirement against whether it is an initiator or recipient?
- Does it check Signed/Endorsing/Encrypted/SupportingTokens requirements?
- Move security events into the SecurityHeaderProcessor.
- Update tests in ws-security module to check security events.
Colm O hEigeartaigh
Talend Community Coder
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com