[
https://issues.apache.org/jira/browse/WSS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Storm Graversen updated WSS-537:
--------------------------------------
Description:
This issue as an extension of WSS-497, which asked for support for the
EncryptedAssertion element. This issue was implemented to the original
requesters satisfaction, and the issue closed.
I'm currently implementing both a webservice client and a webservice provider
that interacts with the danish national STS. This STS issues
EncryptedAssertions, and the current support for EncryptedAssertion seems to
work as long as the token is just a bearer token - but in this setup we are
issued holder-of-key tokens. I have been successful in generating a request in
my client, and parsing/validating the request on the server side, but it
required me to "hack/bypass" some parts of the WSS4J code (as well as a single
place in the CXF codebase).
The binding profile that my client and service must follow is the Basic Liberty
SOAP Binding
(www.projectliberty.org/liberty/content/download/4712/32213/file/Liberty-Basic-SOAP-Binding-1.0_Final.pdf).
I've put the policy and code modifications into the DoubleIt sample code, where
I was able to reproduce the problem.
Note, the following will have a lot of XML, code, etc. If this is not
well-formatted, I will try to attach the samples as files to the issue instead.
I will also add examples on the full payloads between the client and the
service.
I have written a policy section in my service wsdl that fulfills these
requirements
{code:xml}
<wsp:Policy wsu:Id="BasicLibertyPolicy">
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing wsp:Optional="false">
<wsp:Policy />
</wsam:Addressing>
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never";>
<wsp:Policy>
<sp:WssSamlV20Token11 />
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToInitiator";>
<wsp:Policy>
<sp:WssX509V3Token10 />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:ProtectTokens />
<sp:IncludeTimestamp />
<sp:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedSupportingTokens
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702";>
<wsp:Policy>
<sp:IssuedToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient";>
<sp:RequestSecurityTokenTemplate />
<wsp:Policy>
<sp:WssSamlV20Token11 />
</wsp:Policy>
</sp:IssuedToken>
</wsp:Policy>
</sp:SignedSupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
{code}
The first issue is not related to WSS4J, but I mention it here for completeness
- I have a feeling that the same people working on WSS4J will also work on the
CXF code where this issue arises.
1) On the client side, when generating the request, a SecurityTokenReference is
generated (because it is a SignedSupportingToken) that points to the token
issued by the STS, and added to the Security header. This fails on the client
side, because it cannot find any ID on the EncryptedAssertion to put into the
STR.
The EncryptedAssertion looks like this, note that the ID is on the
EncryptedData element inside the EncryptedAssertion, and not on the
EncryptedAssertion itself.
<EncryptedAssertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<xenc:EncryptedData
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";
Type="http://www.w3.org/2001/04/xmlenc#Element";
wsu:Id="encryptedassertion">
...
</xenc:EncryptedData>
</EncryptedAssertion>
The issue lies with this code
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder
(cxf-rt-ws-security v3.0.4) - the method addSignatureParts
String id = null;
if (saml1) {
id = token.getToken().getAttributeNS(null, "AssertionID");
} else {
id = token.getToken().getAttributeNS(null, "ID");
}
In this code it looks for either an AssertionID or ID attribute, depending on
whether we are using a SAML 1 or SAML 2 token. Since the ID is not directly on
the Assertion (EncryptedAssertion in this case) element, this will cause the id
to be NULL, and the code will fail later with a NullPointerException.
I was able to create a valid request by modifying this code to set the correct
ID (the one on the EncryptedData element inside the EncryptedAssertion). I just
hardcoded the ID, as the STS we are using always sets the same ID :) But I
suspect a better solution is to look at the type of Assertion (if it is an
EncryptedAssertion, then look for the EncryptedData child and grab the ID from
there).
2) On the server-side, when validating the signature on the message, WSS4J
looks for a trusted certificate. The KeyInfo element has a reference to the ID
of the EncryptedAssertion (or rather the EncryptedData inside the
EncryptedAssertion), but this cannot be found at this point in time (why?), as
the EncryptedAssertion has already been decrypted, and replaced (the decrypted
Assertion element is available at this point, but the EncryptedAssertion
element is not... exactly why I'm not sure) by an Assertion element, which has
a different ID.
The method getResult(String uri) on org.apache.wss4j.dom.WSDocInfo, has a loop
that looks through all relevant ID's and matches them against the ID refereced
by the KeyInfo element. This fails for the reasons mentioned above.
I changed to code to match the ID of the DECRYPTED Assertion element when
searching. I know this is hardly a useful fix, but it did allow me to continue
- I'm hoping someone has a better solution.
3) Continuing with the signature validation, the code validates the actual
siganture (this is valid) and compares the digests of all the references (they
are all okay except for one!). The digest of the SecurityTokenReference added
to the Security header is not valid. After a bit of debugging I found that the
STR-Transform does not perform identically on the client and server side, or
rather the environment differs.
Note that the STR-Transform runs on the EncryptedData element inside the
EncryptedAssertion element. The EncryptedAssertion part seems to be left out of
the computation.
The EncryptedData element does not have a default namespace, and hence
according to the STR-Transform processing rules, one must be emitted. The code
that does this looks at the parent element, to see if it can grab a namespace
value. When running on the client-side, it will find a parent (the
EncryptedAssertion), and use the default namespace from here
(xmlns="urn:oasis:names:tc:SAML:2.0:assertion"), but ont he server-side, the
parent is NULL (why?), and the empty default namespace is emitted (xmlns="").
This causes the digests to differ.
Again I made a few modifications to the code so it would pass, though not in a
way that I'd dare to show here ;)
The signature is checked in the method verifyXMLSignature in the class
org.apache.wss4j.dom.processor.SignatureProcessor, but the root cause is likely
the fact that the EncryptedData element has been detached from the rest of the
DOM at this point, and doesn't have a parent any more (again why?).
If the issue is caused by me using CXF and WSS4J in a wrong way, then I
apologize and hope that you can help me in the right direction, but since
EncryptedAssertion support is somewhat new, and I could find nothing that could
help me in the code committed on WSS-497, then I'm daring to submit a jira
issue.
was:
This issue as an extension of WSS-497, which asked for support for the
EncryptedAssertion element. This issue was implemented to the original
requesters satisfaction, and the issue closed.
I'm currently implementing both a webservice client and a webservice provider
that interacts with the danish national STS. This STS issues
EncryptedAssertions, and the current support for EncryptedAssertion seems to
work as long as the token is just a bearer token - but in this setup we are
issued holder-of-key tokens. I have been successful in generating a request in
my client, and parsing/validating the request on the server side, but it
required me to "hack/bypass" some parts of the WSS4J code (as well as a single
place in the CXF codebase).
The binding profile that my client and service must follow is the Basic Liberty
SOAP Binding
(www.projectliberty.org/liberty/content/download/4712/32213/file/Liberty-Basic-SOAP-Binding-1.0_Final.pdf).
I've put the policy and code modifications into the DoubleIt sample code, where
I was able to reproduce the problem.
Note, the following will have a lot of XML, code, etc. If this is not
well-formatted, I will try to attach the samples as files to the issue instead.
I will also add examples on the full payloads between the client and the
service.
I have written a policy section in my service wsdl that fulfills these
requirements
{{
<wsp:Policy wsu:Id="BasicLibertyPolicy">
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing wsp:Optional="false">
<wsp:Policy />
</wsam:Addressing>
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never";>
<wsp:Policy>
<sp:WssSamlV20Token11 />
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToInitiator";>
<wsp:Policy>
<sp:WssX509V3Token10 />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:ProtectTokens />
<sp:IncludeTimestamp />
<sp:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedSupportingTokens
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702";>
<wsp:Policy>
<sp:IssuedToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient";>
<sp:RequestSecurityTokenTemplate />
<wsp:Policy>
<sp:WssSamlV20Token11 />
</wsp:Policy>
</sp:IssuedToken>
</wsp:Policy>
</sp:SignedSupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
}}
The first issue is not related to WSS4J, but I mention it here for completeness
- I have a feeling that the same people working on WSS4J will also work on the
CXF code where this issue arises.
1) On the client side, when generating the request, a SecurityTokenReference is
generated (because it is a SignedSupportingToken) that points to the token
issued by the STS, and added to the Security header. This fails on the client
side, because it cannot find any ID on the EncryptedAssertion to put into the
STR.
The EncryptedAssertion looks like this, note that the ID is on the
EncryptedData element inside the EncryptedAssertion, and not on the
EncryptedAssertion itself.
<EncryptedAssertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<xenc:EncryptedData
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";
Type="http://www.w3.org/2001/04/xmlenc#Element";
wsu:Id="encryptedassertion">
...
</xenc:EncryptedData>
</EncryptedAssertion>
The issue lies with this code
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder
(cxf-rt-ws-security v3.0.4) - the method addSignatureParts
String id = null;
if (saml1) {
id = token.getToken().getAttributeNS(null, "AssertionID");
} else {
id = token.getToken().getAttributeNS(null, "ID");
}
In this code it looks for either an AssertionID or ID attribute, depending on
whether we are using a SAML 1 or SAML 2 token. Since the ID is not directly on
the Assertion (EncryptedAssertion in this case) element, this will cause the id
to be NULL, and the code will fail later with a NullPointerException.
I was able to create a valid request by modifying this code to set the correct
ID (the one on the EncryptedData element inside the EncryptedAssertion). I just
hardcoded the ID, as the STS we are using always sets the same ID :) But I
suspect a better solution is to look at the type of Assertion (if it is an
EncryptedAssertion, then look for the EncryptedData child and grab the ID from
there).
2) On the server-side, when validating the signature on the message, WSS4J
looks for a trusted certificate. The KeyInfo element has a reference to the ID
of the EncryptedAssertion (or rather the EncryptedData inside the
EncryptedAssertion), but this cannot be found at this point in time (why?), as
the EncryptedAssertion has already been decrypted, and replaced (the decrypted
Assertion element is available at this point, but the EncryptedAssertion
element is not... exactly why I'm not sure) by an Assertion element, which has
a different ID.
The method getResult(String uri) on org.apache.wss4j.dom.WSDocInfo, has a loop
that looks through all relevant ID's and matches them against the ID refereced
by the KeyInfo element. This fails for the reasons mentioned above.
I changed to code to match the ID of the DECRYPTED Assertion element when
searching. I know this is hardly a useful fix, but it did allow me to continue
- I'm hoping someone has a better solution.
3) Continuing with the signature validation, the code validates the actual
siganture (this is valid) and compares the digests of all the references (they
are all okay except for one!). The digest of the SecurityTokenReference added
to the Security header is not valid. After a bit of debugging I found that the
STR-Transform does not perform identically on the client and server side, or
rather the environment differs.
Note that the STR-Transform runs on the EncryptedData element inside the
EncryptedAssertion element. The EncryptedAssertion part seems to be left out of
the computation.
The EncryptedData element does not have a default namespace, and hence
according to the STR-Transform processing rules, one must be emitted. The code
that does this looks at the parent element, to see if it can grab a namespace
value. When running on the client-side, it will find a parent (the
EncryptedAssertion), and use the default namespace from here
(xmlns="urn:oasis:names:tc:SAML:2.0:assertion"), but ont he server-side, the
parent is NULL (why?), and the empty default namespace is emitted (xmlns="").
This causes the digests to differ.
Again I made a few modifications to the code so it would pass, though not in a
way that I'd dare to show here ;)
The signature is checked in the method verifyXMLSignature in the class
org.apache.wss4j.dom.processor.SignatureProcessor, but the root cause is likely
the fact that the EncryptedData element has been detached from the rest of the
DOM at this point, and doesn't have a parent any more (again why?).
If the issue is caused by me using CXF and WSS4J in a wrong way, then I
apologize and hope that you can help me in the right direction, but since
EncryptedAssertion support is somewhat new, and I could find nothing that could
help me in the code committed on WSS-497, then I'm daring to submit a jira
issue.
> Full support for EncryptedAssertion element
> -------------------------------------------
>
> Key: WSS-537
> URL: https://issues.apache.org/jira/browse/WSS-537
> Project: WSS4J
> Issue Type: Improvement
> Components: WSS4J Core
> Affects Versions: 2.0.4, 2.1.0
> Environment: Tomcat 8, Linux
> Reporter: Brian Storm Graversen
> Assignee: Colm O hEigeartaigh
>
> This issue as an extension of WSS-497, which asked for support for the
> EncryptedAssertion element. This issue was implemented to the original
> requesters satisfaction, and the issue closed.
> I'm currently implementing both a webservice client and a webservice provider
> that interacts with the danish national STS. This STS issues
> EncryptedAssertions, and the current support for EncryptedAssertion seems to
> work as long as the token is just a bearer token - but in this setup we are
> issued holder-of-key tokens. I have been successful in generating a request
> in my client, and parsing/validating the request on the server side, but it
> required me to "hack/bypass" some parts of the WSS4J code (as well as a
> single place in the CXF codebase).
> The binding profile that my client and service must follow is the Basic
> Liberty SOAP Binding
> (www.projectliberty.org/liberty/content/download/4712/32213/file/Liberty-Basic-SOAP-Binding-1.0_Final.pdf).
> I've put the policy and code modifications into the DoubleIt sample code,
> where I was able to reproduce the problem.
> Note, the following will have a lot of XML, code, etc. If this is not
> well-formatted, I will try to attach the samples as files to the issue
> instead. I will also add examples on the full payloads between the client and
> the service.
> I have written a policy section in my service wsdl that fulfills these
> requirements
> {code:xml}
> <wsp:Policy wsu:Id="BasicLibertyPolicy">
> <wsp:ExactlyOne>
> <wsp:All>
> <wsam:Addressing wsp:Optional="false">
> <wsp:Policy />
> </wsam:Addressing>
> <sp:AsymmetricBinding>
> <wsp:Policy>
> <sp:InitiatorToken>
> <wsp:Policy>
> <sp:SamlToken
> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never";>
>
> <wsp:Policy>
>
> <sp:WssSamlV20Token11 />
>
> </wsp:Policy>
> </sp:SamlToken>
> </wsp:Policy>
> </sp:InitiatorToken>
> <sp:RecipientToken>
> <wsp:Policy>
> <sp:X509Token
> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToInitiator";>
>
> <wsp:Policy>
>
> <sp:WssX509V3Token10 />
>
> </wsp:Policy>
> </sp:X509Token>
> </wsp:Policy>
> </sp:RecipientToken>
> <sp:AlgorithmSuite>
> <wsp:Policy>
> <sp:Basic256 />
> </wsp:Policy>
> </sp:AlgorithmSuite>
> <sp:Layout>
> <wsp:Policy>
> <sp:Strict />
> </wsp:Policy>
> </sp:Layout>
> <sp:ProtectTokens />
> <sp:IncludeTimestamp />
>
> <sp:OnlySignEntireHeadersAndBody />
> </wsp:Policy>
> </sp:AsymmetricBinding>
> <sp:SignedSupportingTokens
> xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702";>
> <wsp:Policy>
> <sp:IssuedToken
> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient";>
>
> <sp:RequestSecurityTokenTemplate />
> <wsp:Policy>
>
> <sp:WssSamlV20Token11 />
> </wsp:Policy>
> </sp:IssuedToken>
> </wsp:Policy>
> </sp:SignedSupportingTokens>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
> {code}
> The first issue is not related to WSS4J, but I mention it here for
> completeness - I have a feeling that the same people working on WSS4J will
> also work on the CXF code where this issue arises.
> 1) On the client side, when generating the request, a SecurityTokenReference
> is generated (because it is a SignedSupportingToken) that points to the token
> issued by the STS, and added to the Security header. This fails on the client
> side, because it cannot find any ID on the EncryptedAssertion to put into the
> STR.
> The EncryptedAssertion looks like this, note that the ID is on the
> EncryptedData element inside the EncryptedAssertion, and not on the
> EncryptedAssertion itself.
> <EncryptedAssertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
> <xenc:EncryptedData
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
>
> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";
>
> Type="http://www.w3.org/2001/04/xmlenc#Element";
> wsu:Id="encryptedassertion">
> ...
> </xenc:EncryptedData>
> </EncryptedAssertion>
> The issue lies with this code
> org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder
> (cxf-rt-ws-security v3.0.4) - the method addSignatureParts
> String id = null;
> if (saml1) {
> id = token.getToken().getAttributeNS(null, "AssertionID");
> } else {
> id = token.getToken().getAttributeNS(null, "ID");
> }
> In this code it looks for either an AssertionID or ID attribute, depending on
> whether we are using a SAML 1 or SAML 2 token. Since the ID is not directly
> on the Assertion (EncryptedAssertion in this case) element, this will cause
> the id to be NULL, and the code will fail later with a NullPointerException.
> I was able to create a valid request by modifying this code to set the
> correct ID (the one on the EncryptedData element inside the
> EncryptedAssertion). I just hardcoded the ID, as the STS we are using always
> sets the same ID :) But I suspect a better solution is to look at the type of
> Assertion (if it is an EncryptedAssertion, then look for the EncryptedData
> child and grab the ID from there).
> 2) On the server-side, when validating the signature on the message, WSS4J
> looks for a trusted certificate. The KeyInfo element has a reference to the
> ID of the EncryptedAssertion (or rather the EncryptedData inside the
> EncryptedAssertion), but this cannot be found at this point in time (why?),
> as the EncryptedAssertion has already been decrypted, and replaced (the
> decrypted Assertion element is available at this point, but the
> EncryptedAssertion element is not... exactly why I'm not sure) by an
> Assertion element, which has a different ID.
> The method getResult(String uri) on org.apache.wss4j.dom.WSDocInfo, has a
> loop that looks through all relevant ID's and matches them against the ID
> refereced by the KeyInfo element. This fails for the reasons mentioned above.
> I changed to code to match the ID of the DECRYPTED Assertion element when
> searching. I know this is hardly a useful fix, but it did allow me to
> continue - I'm hoping someone has a better solution.
> 3) Continuing with the signature validation, the code validates the actual
> siganture (this is valid) and compares the digests of all the references
> (they are all okay except for one!). The digest of the SecurityTokenReference
> added to the Security header is not valid. After a bit of debugging I found
> that the STR-Transform does not perform identically on the client and server
> side, or rather the environment differs.
> Note that the STR-Transform runs on the EncryptedData element inside the
> EncryptedAssertion element. The EncryptedAssertion part seems to be left out
> of the computation.
> The EncryptedData element does not have a default namespace, and hence
> according to the STR-Transform processing rules, one must be emitted. The
> code that does this looks at the parent element, to see if it can grab a
> namespace value. When running on the client-side, it will find a parent (the
> EncryptedAssertion), and use the default namespace from here
> (xmlns="urn:oasis:names:tc:SAML:2.0:assertion"), but ont he server-side, the
> parent is NULL (why?), and the empty default namespace is emitted (xmlns="").
> This causes the digests to differ.
> Again I made a few modifications to the code so it would pass, though not in
> a way that I'd dare to show here ;)
> The signature is checked in the method verifyXMLSignature in the class
> org.apache.wss4j.dom.processor.SignatureProcessor, but the root cause is
> likely the fact that the EncryptedData element has been detached from the
> rest of the DOM at this point, and doesn't have a parent any more (again
> why?).
> If the issue is caused by me using CXF and WSS4J in a wrong way, then I
> apologize and hope that you can help me in the right direction, but since
> EncryptedAssertion support is somewhat new, and I could find nothing that
> could help me in the code committed on WSS-497, then I'm daring to submit a
> jira issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
