ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Storm Graversen (JIRA)" <j...@apache.org>
Subject [jira] [Created] (WSS-537) Full support for EncryptedAssertion element
Date Wed, 29 Apr 2015 09:57:06 GMT
Brian Storm Graversen created WSS-537:
-----------------------------------------

             Summary: 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.1.0, 2.0.4
         Environment: Tomcat 8, Linux
            Reporter: Brian Storm Graversen
            Assignee: Colm O hEigeartaigh


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
(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.

Note, the following will have a lot of XML, code, etc. If this is not well-formatted, I will
try to attach the samples as files to the issue instead. I will also add examples on the full
payloads between the client and the service.

I have written a policy section in my service wsdl that fulfills these requirements

	<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>

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.

<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>

The issue lies with this code

org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder  (cxf-rt-ws-security
v3.0.4) - the method addSignatureParts

    String id = null;
    if (saml1) {
        id = token.getToken().getAttributeNS(null, "AssertionID");
    } else {
        id = token.getToken().getAttributeNS(null, "ID");
    }

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


Mime
View raw message