ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sagara Gunathunga <sagara.gunathu...@gmail.com>
Subject Re: [ATTN] - WSS4J 2.0 work plan
Date Fri, 24 Feb 2012 06:47:28 GMT
On Thu, Feb 23, 2012 at 4:23 PM, 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? 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.
>

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.

Thanks !


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


-- 
Sagara Gunathunga

Blog      - http://ssagara.blogspot.com
Web      - http://people.apache.org/~sagara/
LinkedIn - http://www.linkedin.com/in/ssagara

Mime
View raw message