My 2cs below. On Thu, Feb 23, 2012 at 5:53 AM, Colm O hEigeartaigh <[email protected]>wrote:
> Hi all, > > 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 > and resolve. > > Colm. > > ----- > > 1) Open questions > - Apache Santuario contains the (DOM)-based XML signature and > encryption code that WSS4J (and many other projects) rely on. The > swssf > 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? The less redundancy, the better IMO. > 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 > a halt. > I'm mixed on this one. Will this reduce duplication further? If so, +1. Will this let more bugs be fixed because everything is under one roof? If so, +1. <rant> Either way, please give the merged project an intelligible name, WSS4J is perfectly crystal clear, the tin says WSS4J and I know what to expect. Why in the world was XML Security renamed to "Santu-a-r-i-o" -- I have to carefully type this nonsense name -- is beyond my comprehension. Is it somebody's kid's name? Apple Lisa anyone? Is it the birthplace of someone I should care about? It feels like an exercise in obfuscation. Give me bricks with decent names so I can build a mansion, then I can give that a funky name. </rant> > - 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? Java 1.5 is dead, let's move on to /at least/ Java 6. > If it is, I guess we > could implement our own Deque classes. Please don't. > - The swssf branch currently uses "org.swssf", WSS4J currently uses > "org.apache.ws.security". Does anyone have any suggestions for how we > should > change the swssf package names? > Remind myself that SWSSF = Streaming WebServices Security Framework So the difference with WSS4J is the "Streaming" part, so: - org.apache.ws.security.streaming? - org.apache.ws.security.stream? - org.apache.ws.security.stax? and other non-stax code under - org.apache.ws.security? Gary > > 2) Refactoring > - 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 > (each should > 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 > CallbackHandler. > -- Add support for CRL's. > > 4) SAML > > - 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 > non-policy case. > > 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 > http://coders.talend.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- E-Mail: [email protected] | [email protected] JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
