ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [ATTN] - WSS4J 2.0 work plan
Date Thu, 23 Feb 2012 15:43:37 GMT
My 2cs below.

On Thu, Feb 23, 2012 at 5:53 AM, Colm O hEigeartaigh <coheigea@apache.org>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: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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

Mime
View raw message