You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2012/02/23 11:53:05 UTC
[ATTN] - WSS4J 2.0 work plan
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.
- 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.
- 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
Re: [ATTN] - WSS4J 2.0 work plan
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Feb 29, 2012 at 11:13 AM, Colm O hEigeartaigh
<co...@apache.org>wrote:
> Thanks for all the responses. So to address the open questions:
>
> 1) Should streaming-xml-security go into Santuario or WSS4J? Should
> all of WSS4J move to Santuario?
>
> The consensus seems to be that streaming-xml-security should go into
> Santuario - and not as a sub-project, and that WSS4J 2.0 should stay
> where it is. I will initiate a discussion with the Santuario project
> to see what they think of the idea.
>
> 2) Do we require JDK 1.5 support?
>
> I propose to just leave this issue for now. Officially we will drop
> 1.5 support in the development cycle, and possibly revisit nearer the
> time of the 2.0 release if there are any major objections from
> downstream projects.
>
> 3) Package names.
>
> Let's go with something like "org.apache.ws.security.stream". Should
> we add a "2" in there somewhere to differentiate package names from
> the 1.6.x releases?
>
FWIW, at Apache Commons, our guideline is to change package names when we
break binary compatibility.
Gary
>
> Colm.
>
> ---------------------------------------------------------------------
> 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
Re: [ATTN] - WSS4J 2.0 work plan
Posted by Colm O hEigeartaigh <co...@apache.org>.
Thanks for all the responses. So to address the open questions:
1) Should streaming-xml-security go into Santuario or WSS4J? Should
all of WSS4J move to Santuario?
The consensus seems to be that streaming-xml-security should go into
Santuario - and not as a sub-project, and that WSS4J 2.0 should stay
where it is. I will initiate a discussion with the Santuario project
to see what they think of the idea.
2) Do we require JDK 1.5 support?
I propose to just leave this issue for now. Officially we will drop
1.5 support in the development cycle, and possibly revisit nearer the
time of the 2.0 release if there are any major objections from
downstream projects.
3) Package names.
Let's go with something like "org.apache.ws.security.stream". Should
we add a "2" in there somewhere to differentiate package names from
the 1.6.x releases?
Colm.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: [ATTN] - WSS4J 2.0 work plan
Posted by Daniel Kulp <dk...@apache.org>.
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
Re: [ATTN] - WSS4J 2.0 work plan
Posted by Sagara Gunathunga <sa...@gmail.com>.
On Thu, Feb 23, 2012 at 4:23 PM, Colm O hEigeartaigh <co...@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
Re: [ATTN] - WSS4J 2.0 work plan
Posted by Gary Gregory <ga...@gmail.com>.
My 2cs below.
On Thu, Feb 23, 2012 at 5:53 AM, Colm O hEigeartaigh <co...@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