Well, the issue I'm having is definitely occurring during the signing
operation. The handleActAs method below is called by my SamlCustomHandler's
handle method, which I neglected to post earlier because it's main mission in
life is to route between a SAML1 custom handler and a SAML2 custom handler. But
I made one other small change this morning, to disable signing in the
SAMLTokenProvider when there is an ActAs in play that will result in an Advice
element:
public void handle(AssertionWrapper assertionWrapper,
TokenProviderParameters tokenParameters)
throws STSException
{
TokenRequirements tokenRequirements =
tokenParameters.getTokenRequirements();
ReceivedToken actAs = tokenRequirements.getActAs();
if ( actAs != null ) {
if ( actAs.isUsernameToken() || actAs.isBinarySecurityToken() ||
!actAs.isDOMElement() ) {
throw new STSException("Illegal token type in ActAs element");
}
samlTokenProvider.setSignToken(false);
String tokenType = tokenRequirements.getTokenType();
if ( WSConstants.WSS_SAML_TOKEN_TYPE.equals(tokenType) ) {
saml1CustomHandler.handleActAs(assertionWrapper, actAs,
tokenParameters);
} else if ( WSConstants.WSS_SAML2_TOKEN_TYPE.equals(tokenType) ) {
saml2CustomHandler.handleActAs(assertionWrapper, actAs,
tokenParameters);
}
} else {
samlTokenProvider.setSignToken(true);
}
With the setSignToken(false) in place, the assertion that gets issued has an
Advice element with an Assertion that has its signature intact. Of course, the
parent assertion is unsigned now, so that is my next problem to solve.
Stephen W. Chappell
From: Chappell, Stephen CTR (FAA)
Sent: Friday, March 13, 2015 3:09 PM
To: [email protected]
Subject: Adding Advice in CXF 2.7.13 STS
I am revisiting some STS code I was working on some time ago and found a sort
of major bug. I have a requirement to issue tokens with Advice when my RST has
an ActAs. At the time, I implemented that using a SAMLCustomHandler derivative,
which seemed to work until I started writing validators. Then I noticed that
the signature value was getting stripped out of the advice assertion.
My handling code looks like this:
public void handleActAs(AssertionWrapper assertionWrapper, ReceivedToken
actAs)
{
Advice advice = (Advice)buildXMLObject(Advice.DEFAULT_ELEMENT_NAME);
AssertionWrapper adviceAssertion = null;
try {
adviceAssertion = new AssertionWrapper((Element)actAs.getToken());
}
catch ( WSSecurityException ex ) {
throw new STSException("Cannot handle ActAs token");
}
if ( adviceAssertion != null && adviceAssertion.getSaml1() != null ) {
advice.getAssertions().add(adviceAssertion.getSaml1());
assertionWrapper.getSaml1().setAdvice(advice);
} else {
LOG.log(Level.INFO, "ActAs is not SAML1");
}
}
(there's similar code for SAML2). When I do this, my signature on the inner
assertion ends up like this:
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference
URI="#_0A9C1B4AD3BAA6657514262401210901">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue/>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue/>
Originally, the digest method was SHA256 and there were digest and signature
values. Am I screwing something up when I add the assertion? Does anyone have
any suggestions for tracking this down?
I have seen this before when mixing some WSS4J and OpenSaml assertion building,
but aside from the Advice that's not really the case here. I did fix that case,
but those fixes will not readily translate to hear. Has anyone successfully
added Advice in the STS?
Thanx,
Stephen W. Chappell
