ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: [ATTN] - WSS4J 2.0 work plan
Date Tue, 28 Feb 2012 21:48:29 GMT
On Thursday, February 23, 2012 10:53:05 AM Colm O hEigeartaigh wrote:
> 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? 

Would it half to be a sub-project?   Could it just go into the xmlsec jar as 
additional functionality?     I'd kind of prefer to see all the xml sig/enc 
stuff in one place.


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

Not sure I'd go that far...  Hmm....  Really kind of different purposes.   
There are projects that use the xmlsec stuff directly without the WSS4J stuff.  


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

I'm ok with dropping 1.5 for this.   That said, we'll need to approach the 
projects that use WSS4J and let them know this will be a requirement going 
forward.   Primarily that is Axis2/Rampart and CXF, but may be others.   I 
think Spring-WS allows using WSS4J as well.    I think Camel has a couple 
direct uses, but they dropped support for 1.5 a while ago.     That said, with 
1.6.x approaching EOL later this year, dropping support for 1.5 even in those 
communities is becoming increasingly more acceptable.

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

Likely one of Gary's suggestions.

The rest of this just looks like a ton of work, but definitely looks 
promising.  :-)


Dan



 
> 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.
-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
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


Mime
View raw message