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
Engility Corporation, SWIM Task Lead
William J. Hughes Technical Center, FAA
Information Security Team, ANG-B31
(609) 485-6710 (office)
(609) 980-9239 (cell)
[EngilityLogo]
