[
https://issues.apache.org/jira/browse/WSS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539264#comment-14539264
]
Brian Storm Graversen commented on WSS-537:
-------------------------------------------
Hi Colm.
The response from the STS already contains a RAR (and a RUR for that matter),
but they reference the encrypted Assertion (or rather the EncryptedData element
inside the EncryptedAssertion element)
{code:xml}
<wst:RequestedAttachedReference
xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512";>
<wsse:SecurityTokenReference>
<wsse:Reference
URI="#encryptedassertion" />
</wsse:SecurityTokenReference>
</wst:RequestedAttachedReference>
{code}
I had a talk with the agency that is responsible for the STS, to discuss the
possibility of not using encrypted assertions, but unfortunately that was not
an option. Before I suggest using encrypted attributes inside a "plain-text"
Assertion element, how well is that supported by CXF/WSS4J?
I did a bit of tinkering with using a reference to the decrypted Assertion, but
the problem, as far as I got, is signing the SecurityTokenReference element
added to the header (required by the Liberty Basic SOAP Binding profile). With
a reference to the decrypted element, I was no longer able to get CXF to sign
the SecurityTokenReference - I'm assuming because the STR-Transform algorithm
could not find the bytes to include in the message to sign (the decrypted
assertion does not exists on the client side).
> 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
> Attachments: request.xml, response.xml
>
>
> 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
> (http://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.
> 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.
> {code:xml}
> <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>
> {code}
> The issue lies with this code
> org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder
> (cxf-rt-ws-security v3.0.4) - the method addSignatureParts
> {code}
> String id = null;
> if (saml1) {
> id = token.getToken().getAttributeNS(null, "AssertionID");
> } else {
> id = token.getToken().getAttributeNS(null, "ID");
> }
> {code}
> 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]
