[
https://issues.apache.org/jira/browse/WSS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14523215#comment-14523215
]
Colm O hEigeartaigh commented on WSS-537:
-----------------------------------------
With regards to the third issue, as part of the decryption process, the
encrypted element is replaced in the DOM tree by the decrypted Element, and the
encrypted element itself is orphaned. Hence no parent. IMO the correct thing
here would be to change the client code not to use a STR in this scenario. The
STR is only designed to be used with a SAML Assertion. So I think you can
resolve this issue + create a JIRA in CXF for that one.
Colm.
> 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]
