ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colm O hEigeartaigh (JIRA)" <>
Subject [jira] [Commented] (WSS-537) Full support for EncryptedAssertion element
Date Fri, 01 May 2015 13:50:06 GMT


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.


> Full support for EncryptedAssertion element
> -------------------------------------------
>                 Key: WSS-537
>                 URL:
>             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
> 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 (
> 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="">
> 									<wsp:Policy>
> 										<sp:WssSamlV20Token11 />
> 									</wsp:Policy>
> 								</sp:SamlToken>
> 							</wsp:Policy>
> 						</sp:InitiatorToken>
> 						<sp:RecipientToken>
> 							<wsp:Policy>
> 								<sp:X509Token sp:IncludeToken="">
> 									<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="">
> 					<wsp:Policy>
> 						<sp:IssuedToken sp:IncludeToken="">
> 							<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=""
> 						xmlns:xenc=""
> 						Type=""
> 						wsu:Id="encryptedassertion">
> 	...
> 	</xenc:EncryptedData>
> </EncryptedAssertion>
> {code}
> The issue lies with this code
>  (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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message