[prev in list] [next in list] [prev in thread] [next in thread]
List: xmlrpc-user
Subject: [jira] [Commented] (WSS-537) Full support for EncryptedAssertion element
From: "Brian Storm Graversen (JIRA)" <jira () apache ! org>
Date: 2015-04-29 15:32:06
Message-ID: JIRA.12825884.1430301419000.22395.1430321526375 () Atlassian ! JIRA
[Download RAW message or body]
[ https://issues.apache.org/jira/browse/WSS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14519562#comment-14519562 \
]
Brian Storm Graversen commented on WSS-537:
-------------------------------------------
Hi Colm.
so I was to curious to wait until tomorrow, so I did a quick compile and run, and it \
fixed the client-side issue. In fact the changes you made to AbstractBindingBuilder \
where enough in my case and I didn't need the change to AbstractSTSClient - but it \
might help in other cases.
> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic