You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by bimjoeipa <jo...@ipaustralia.gov.au> on 2014/02/13 03:28:44 UTC
CXF Service can't process PublicKey SAML Sender Vouches IssuedToken
in WS-Policy
Hi,
I've found a problem with WS-Policy in CXF, where it can't process a SAML
Token with the Sender Vouches confirmation method when using PublicKey
KeyType in WS-Policy.
The problem surfaces in:
org.apache.cxf.ws.security.wss4j.policyvalidators.IssuedTokenPolicyValidator.checkIssuedTokenTemplate(Element,
AssertionWrapper)
When it is checking the KeyType and then it matches the "PublicKey", it
looks up the assertion subjectKeyInfo, however that is only set for the
Holder of Key scenario as seen here:
org.apache.ws.security.saml.ext.AssertionWrapper.parseHOKSubject(RequestData,
WSDocInfo)
So, potentially the solution in checkIssuedTokenTemplate could be to only
check the subjectKeyInfo for PublicKey when the confirmation method is
Holder of Key, ie:
else if (content.endsWith("PublicKey") &&
OpenSAMLUtil.isMethodHolderOfKey(confirmMethod))
Unless there is some check that should that needs to be done in the Sender
Vouches scenario?
I have attached the WS-Policy
<http://cxf.547215.n5.nabble.com/file/n5739904/DoubleItAsymmetricIssuedTokenPolicy.xml>
I am using.
Thanks,
Joel
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by bimjoeipa <jo...@ipaustralia.gov.au>.
coheigea wrote
> The problem here is that the endpoint is requiring a "PublicKey" KeyType,
> yet the received (Sender Vouches) assertion does not contain a PublicKey.
> What I would suggest here is that you remove the KeyType from the policy
> of
> the WSDL, but set up your (STS) clients to send a PublicKey KeyType to the
> STS via configuration (configure the "keyType" property of the STSClient).
> Would this work for you?
This worked perfectly! Thanks!
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5740378.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Joel,
The problem here is that the endpoint is requiring a "PublicKey" KeyType,
yet the received (Sender Vouches) assertion does not contain a PublicKey.
What I would suggest here is that you remove the KeyType from the policy of
the WSDL, but set up your (STS) clients to send a PublicKey KeyType to the
STS via configuration (configure the "keyType" property of the STSClient).
Would this work for you?
Colm.
On Fri, Feb 21, 2014 at 12:40 AM, bimjoeipa <joel.pearson@ipaustralia.gov.au
> wrote:
> Hi Colm,
>
>
> coheigea wrote
> > I don't think your change
> > to the IssuedTokenPolicyValidator should be necessary. The
> > SamlAssertionWrapper in WSS4J now tries to parse the Subject KeyInfo for
> > the non-HolderOfKey case. So there should be a SubjectKeyInfo there ready
> > for validation, for the sender-vouches case. Could you debug into the
> code
> > here and let me know why it is not working?
>
> I debugged through the code and found that Subject KeyInfo is not set
> because the element is simply not in the Assertion.
>
> As far as I'm aware Sender Vouches doesn't contain a Subject KeyInfo, that
> is only for Holder of Key right? Because there is no X.509 certificate
> associated with the Subject.
>
> This IBM Link
> <
> http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Fcwbs_samltokenprofilespec.html
> >
> shows different examples of SAML Subject Confirmations, and Holder of Key
> is
> the only one that has a KeyInfo element, both bearer and sender vouches
> don't.
>
> So in the IssuedTokenPolicyValidator I still think it's only valid to check
> for a Subject KeyInfo in the Holder of Key case. This would probably apply
> to SymmetricKey too I'm guessing.
>
> I've managed to work around the problem to some degree by simply not
> specifying a KeyType in the WS-Policy, which means that it defaults to
> SymmetricKey, but doesn't actually validate it. However this caused
> problems
> with our STS because it doesn't actually support SymmetricKey, I did manage
> to patch it, so that it doesn't explode, but it's not an ideal solution.
>
> Thanks,
>
> Joel
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5740280.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by bimjoeipa <jo...@ipaustralia.gov.au>.
Hi Colm,
coheigea wrote
> I don't think your change
> to the IssuedTokenPolicyValidator should be necessary. The
> SamlAssertionWrapper in WSS4J now tries to parse the Subject KeyInfo for
> the non-HolderOfKey case. So there should be a SubjectKeyInfo there ready
> for validation, for the sender-vouches case. Could you debug into the code
> here and let me know why it is not working?
I debugged through the code and found that Subject KeyInfo is not set
because the element is simply not in the Assertion.
As far as I'm aware Sender Vouches doesn't contain a Subject KeyInfo, that
is only for Holder of Key right? Because there is no X.509 certificate
associated with the Subject.
This IBM Link
<http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Fcwbs_samltokenprofilespec.html>
shows different examples of SAML Subject Confirmations, and Holder of Key is
the only one that has a KeyInfo element, both bearer and sender vouches
don't.
So in the IssuedTokenPolicyValidator I still think it's only valid to check
for a Subject KeyInfo in the Holder of Key case. This would probably apply
to SymmetricKey too I'm guessing.
I've managed to work around the problem to some degree by simply not
specifying a KeyType in the WS-Policy, which means that it defaults to
SymmetricKey, but doesn't actually validate it. However this caused problems
with our STS because it doesn't actually support SymmetricKey, I did manage
to patch it, so that it doesn't explode, but it's not an ideal solution.
Thanks,
Joel
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5740280.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by Colm O hEigeartaigh <co...@apache.org>.
Thanks, I've fixed the other BSP issue in WSS4J. I don't think your change
to the IssuedTokenPolicyValidator should be necessary. The
SamlAssertionWrapper in WSS4J now tries to parse the Subject KeyInfo for
the non-HolderOfKey case. So there should be a SubjectKeyInfo there ready
for validation, for the sender-vouches case. Could you debug into the code
here and let me know why it is not working?
Colm.
On Wed, Feb 19, 2014 at 10:31 PM, bimjoeipa <joel.pearson@ipaustralia.gov.au
> wrote:
> Hi Colm,
>
> What do you suggest about my original problem of validating the "PublicKey"
> KeyType? Is my suggestion of "else if (content.endsWith("PublicKey") &&
> OpenSAMLUtil.isMethodHolderOfKey(confirmMethod))" in
>
> org.apache.cxf.ws.security.wss4j.policyvalidators.IssuedTokenPolicyValidator.checkIssuedTokenTemplate
> a valid solution?
>
> Thanks,
>
> Joel
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5740199.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by bimjoeipa <jo...@ipaustralia.gov.au>.
Hi Colm,
What do you suggest about my original problem of validating the "PublicKey"
KeyType? Is my suggestion of "else if (content.endsWith("PublicKey") &&
OpenSAMLUtil.isMethodHolderOfKey(confirmMethod))" in
org.apache.cxf.ws.security.wss4j.policyvalidators.IssuedTokenPolicyValidator.checkIssuedTokenTemplate
a valid solution?
Thanks,
Joel
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5740199.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by Colm O hEigeartaigh <co...@apache.org>.
If your WSS4J jars are saying "beta" then that's an old version of CXF
3.0.0-SNAPSHOT. Can you try with the latest CXF SNAPSHOT jars? (The WSS4J
jars should be 2.0.0-rc1).
Colm.
On Sun, Feb 16, 2014 at 2:08 AM, langeS <la...@gmail.com> wrote:
> Having the same issue with a sender vouches saml token. I'm using
> 3.0.0-SNAPSHOT and I believe I have the correct jars for wss4j. 2.0.0 most
> say beta. I'm not sure what the issue is because as soon as it tries to
> invoke the WSS4jInInterception it logs "Finished servicing http request on
> thread" and no additional logging. This is running in Glassfish v.2.1.1
> which could be adding to the problem. I think I worked out the classloader
> issues. My service was running good without WS security.
>
> 2014-02-15 19:57:11.865 [DEBUG]
> org.apache.cxf.phase.PhaseInterceptorChain:305 - Invoking handleMessage on
> interceptor org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor@1676032
> 2014-02-15 19:57:11.866 [DEBUG]
> org.apache.cxf.transport.servlet.ServletController:228 - Finished servicing
> http request on thread: Thread[httpSSLWorkerThread-20243-1,10,Grizzly]
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5740029.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by langeS <la...@gmail.com>.
Having the same issue with a sender vouches saml token. I'm using
3.0.0-SNAPSHOT and I believe I have the correct jars for wss4j. 2.0.0 most
say beta. I'm not sure what the issue is because as soon as it tries to
invoke the WSS4jInInterception it logs "Finished servicing http request on
thread" and no additional logging. This is running in Glassfish v.2.1.1
which could be adding to the problem. I think I worked out the classloader
issues. My service was running good without WS security.
2014-02-15 19:57:11.865 [DEBUG]
org.apache.cxf.phase.PhaseInterceptorChain:305 - Invoking handleMessage on
interceptor org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor@1676032
2014-02-15 19:57:11.866 [DEBUG]
org.apache.cxf.transport.servlet.ServletController:228 - Finished servicing
http request on thread: Thread[httpSSLWorkerThread-20243-1,10,Grizzly]
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5740029.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by bimjoeipa <jo...@ipaustralia.gov.au>.
coheigea wrote
> Thanks, this is now fixed:
>
> http://svn.apache.org/viewvc/webservices/wss4j/trunk/ws-security-dom/src/?view=log
Thanks Colm, the same patch needs to be applied at 767 too:
diff --git
a/ws-security-dom/src/main/java/org/apache/wss4j/dom/processor/SignatureProcessor.java
b/ws-security-dom/src/main/java/org/apache
index 8f01968..795a7a7 100644
---
a/ws-security-dom/src/main/java/org/apache/wss4j/dom/processor/SignatureProcessor.java
+++
b/ws-security-dom/src/main/java/org/apache/wss4j/dom/processor/SignatureProcessor.java
@@ -764,7 +764,7 @@ public class SignatureProcessor implements Processor {
if (WSConstants.C14N_EXCL_OMIT_COMMENTS.equals(algorithm))
{
parameterSpec = transform.getParameterSpec();
- if (!(parameterSpec instanceof ExcC14NParameterSpec)) {
+ if (parameterSpec != null && !(parameterSpec instanceof
ExcC14NParameterSpec)) {
bspEnforcer.handleBSPRule(BSPRule.R5407);
}
}
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5740198.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by Colm O hEigeartaigh <co...@apache.org>.
Thanks, this is now fixed:
http://svn.apache.org/viewvc/webservices/wss4j/trunk/ws-security-dom/src/?view=log
Colm.
On Tue, Feb 18, 2014 at 5:45 AM, bimjoeipa
<jo...@ipaustralia.gov.au>wrote:
> Just re-read my example for wss4j
>
> probably should be "if (parameterSpec != null && !(parameterSpec instanceof
> ExcC14NParameterSpec)) {" instead of "if (parameterSpec == null ||
> !(parameterSpec instanceof ExcC14NParameterSpec)) {"
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5740082.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by bimjoeipa <jo...@ipaustralia.gov.au>.
Just re-read my example for wss4j
probably should be "if (parameterSpec != null && !(parameterSpec instanceof
ExcC14NParameterSpec)) {" instead of "if (parameterSpec == null ||
!(parameterSpec instanceof ExcC14NParameterSpec)) {"
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5740082.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by bimjoeipa <jo...@ipaustralia.gov.au>.
coheigea wrote
> Could you try updating your CXF trunk code? It's using WSS4J 2.0.0-rc1,
> and
> not the SNAPSHOT, as of a few days now.
Can't believe I forgot to do that, I see that you changed it on the 7th Feb,
and it builds ok now.
coheigea wrote
> CXF 2.7.x does not support processing a SAML sender-vouches Assertion as
> part of an IssuedToken policy. However, this is currently supported on CXF
> trunk if you want to try with CXF 3.0.0-SNAPSHOT. I don't want to backport
> any of the changes for fear of breaking backwards compatibility for other
> scenarios.
I have exactly that same problem as in the 2.7.x series, it looks like
org.apache.cxf.ws.security.wss4j.policyvalidators.IssuedTokenPolicyValidator.checkIssuedTokenTemplate(Element,
SamlAssertionWrapper) needs the same patch I mentioned originally.
Additionally, I had other problems caused by WSS4J (when talking to my 3rd
party STS), I am getting this error:
"Caused by: org.apache.wss4j.common.ext.WSSecurityException: BSP:R5404: Any
CANONICALIZATION_METHOD Algorithm attribute MUST have a value of
"http://www.w3.org/2001/10/xml-exc-c14n#" indicating that it uses Exclusive
C14N without comments for canonicalization"
I looked into it and I believe
org.apache.wss4j.dom.processor.SignatureProcessor.checkBSPCompliance(XMLSignature,
BSPEnforcer) is interpreting R5404
<http://www.ws-i.org/profiles/basicsecurityprofile-1.1.html#R5404> in a
way that is more restrictive than the standard specifies.
The standard is saying "Any CANONICALIZATION_METHOD Algorithm attribute MUST
have a value of "http://www.w3.org/2001/10/xml-exc-c14n#" indicating that it
uses Exclusive C14N without comments for canonicalization.", but WSS4J is
also essentially adding "AND some parameter specifications MUST be defined"
For example my reading of the spec says that:
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
should be sufficient, but it is rejected if there isn't some parameter like
so:
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="soap"/>
</ds:CanonicalizationMethod>
Looking at the streaming version:
org.apache.wss4j.stax.impl.processor.input.WSSSignatureInputHandler.checkBSPCompliance(InputProcessorChain,
SignatureType), it looks like it is doing it the right way:
CanonicalizationMethodType canonicalizationMethodType =
signatureType.getSignedInfo().getCanonicalizationMethod();
if
(!WSSConstants.NS_C14N_EXCL.equals(canonicalizationMethodType.getAlgorithm()))
{
securityContext.handleBSPRule(BSPRule.R5404);
}
In 2.0.0-rc1 BSPRule.R5404 is already checked on line 722, but the extra
more restrictive rule is applied on 736 and 767. I'm guessing the
additional rules are checking that the parameters are actually c14n
parameters, but it isn't checking the null case.
Maybe " if (!(parameterSpec instanceof ExcC14NParameterSpec)) {" should
become " if (parameterSpec == null || !(parameterSpec instanceof
ExcC14NParameterSpec)) {" ?
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5740081.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi,
Could you try updating your CXF trunk code? It's using WSS4J 2.0.0-rc1, and
not the SNAPSHOT, as of a few days now.
Colm.
On Fri, Feb 14, 2014 at 1:44 AM, bimjoeipa
<jo...@ipaustralia.gov.au>wrote:
> Hi Colm,
>
> I tried to build CXF trunk 3.0.0-SNAPSHOT for about an hour without
> success,
> due to problems with the WSS4J 2.0.0-SNAPSHOT dependency. It seems in
> wss4j
> you removed a ConversationException class last week, but cxf trunk hasn't
> caught up yet.
>
> So cxf-rt-ws-security won't build for me.
>
> I got the git repo for wss4j, and tried rolling back to the 9th of January
> when you changed CXF trunk from 2.0-SNAPSHOT to 2.0.0-SNAPSHOT, but then
> that failed due to other dependencies on xmlsec, so I gave up.
>
> Am I doing something wrong?
>
> Thanks,
>
> Joel
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5739973.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by bimjoeipa <jo...@ipaustralia.gov.au>.
Hi Colm,
I tried to build CXF trunk 3.0.0-SNAPSHOT for about an hour without success,
due to problems with the WSS4J 2.0.0-SNAPSHOT dependency. It seems in wss4j
you removed a ConversationException class last week, but cxf trunk hasn't
caught up yet.
So cxf-rt-ws-security won't build for me.
I got the git repo for wss4j, and tried rolling back to the 9th of January
when you changed CXF trunk from 2.0-SNAPSHOT to 2.0.0-SNAPSHOT, but then
that failed due to other dependencies on xmlsec, so I gave up.
Am I doing something wrong?
Thanks,
Joel
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904p5739973.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Service can't process PublicKey SAML Sender Vouches
IssuedToken in WS-Policy
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Joel,
CXF 2.7.x does not support processing a SAML sender-vouches Assertion as
part of an IssuedToken policy. However, this is currently supported on CXF
trunk if you want to try with CXF 3.0.0-SNAPSHOT. I don't want to backport
any of the changes for fear of breaking backwards compatibility for other
scenarios.
Colm.
On Thu, Feb 13, 2014 at 2:28 AM, bimjoeipa
<jo...@ipaustralia.gov.au>wrote:
> Hi,
>
> I've found a problem with WS-Policy in CXF, where it can't process a SAML
> Token with the Sender Vouches confirmation method when using PublicKey
> KeyType in WS-Policy.
>
> The problem surfaces in:
>
> org.apache.cxf.ws.security.wss4j.policyvalidators.IssuedTokenPolicyValidator.checkIssuedTokenTemplate(Element,
> AssertionWrapper)
>
> When it is checking the KeyType and then it matches the "PublicKey", it
> looks up the assertion subjectKeyInfo, however that is only set for the
> Holder of Key scenario as seen here:
>
> org.apache.ws.security.saml.ext.AssertionWrapper.parseHOKSubject(RequestData,
> WSDocInfo)
>
> So, potentially the solution in checkIssuedTokenTemplate could be to only
> check the subjectKeyInfo for PublicKey when the confirmation method is
> Holder of Key, ie:
>
> else if (content.endsWith("PublicKey") &&
> OpenSAMLUtil.isMethodHolderOfKey(confirmMethod))
>
> Unless there is some check that should that needs to be done in the Sender
> Vouches scenario?
>
> I have attached the WS-Policy
> <
> http://cxf.547215.n5.nabble.com/file/n5739904/DoubleItAsymmetricIssuedTokenPolicy.xml
> >
> I am using.
>
> Thanks,
>
> Joel
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-Service-can-t-process-PublicKey-SAML-Sender-Vouches-IssuedToken-in-WS-Policy-tp5739904.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com