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 (JIRA)" <ji...@apache.org> on 2015/05/01 13:16:06 UTC
[jira] [Commented] (WSS-537) Full support for EncryptedAssertion
element
[ https://issues.apache.org/jira/browse/WSS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14523058#comment-14523058 ]
Colm O hEigeartaigh commented on WSS-537:
-----------------------------------------
Thanks for verifying the fix for the first point. With respect to the second point...IMO the request is not valid and WSS4J can't be expected to validate it. The Signature KeyInfo references an EncryptedData structure, which does not make sense. The solution here is for the STS you are using to return the Id of the Assertion in a "RequestedAttachedReference" field. This would then be used by CXF to reference the Assertion (and not the wsu:Id of the EncryptedData structure).
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: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org