OpenSAML user discussion

[Brent Putman <>]

On 10/22/10 11:39 AM, Jean-Michel Tremblay wrote:
> Hi,
> 


> I'm using OpenSAML 2.4.0 (Java) to generate SAML 2.0 requests and responses
> back and forth between my junit test and my actual SAML service (also using
> OpenSAML).  
> 

So to be clear, both the signing and validation sides in the failure
case are using OpenSAML Java?



> 
> Both requests and responses are signed.  Signature validation works well in
> all cases so far except when a response contains an AttributeValue of type
> XSString or XSInteger, in which case  PKIXSignatureTrustEngine's validate()
> method returns false.   An attribute without value doesn't cause any 
> problem. 
> And the same AttributeValue element with no "type" (no XML attribute) works
> fine as well. 


We routinely use xsi:type's in AttributeValues generated by the
Shibboleth IdP, and that gets validated fine by both Java OpenSAML and
other SAML impls (C++ OpenSAML, probably SimpleSAML, etc).  So I'm
somewhat skeptical that the cause of the failure has anything to do with
the xsi:type and xsi namespace decl being present.  It *might* possibly
have something to do with the exclusive c14n inclusive namespace prefix
handling, which is new in 2.4.0, but that's known to work also within
Shib.  At the very least we'd need to see a lot more debug output from
both the signing and validating sides.  See this wiki page for how to
get that from OpenSAML Java and C++:

https://spaces.internet2.edu/display/OpenSAML/OSTwoUserManSigErrors


Basically need to compare the canonicalized octets from both the signing
and validation sides.

Might also be useful to turn on debug logging for OpenSAML, to see what
the PKIX trust engine and related security code is actually doing.  Lots
of things can go wrong with the PKIX validation approach.



> 
> The attribute statement is marshalled as this:
> <saml2:AttributeStatement>
> <saml2:Attribute Name="IsAccountIdLookup"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
> <saml2:Attribute Name="PartnerId"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:type="xs:integer">32767</saml2:AttributeValue>
> </saml2:Attribute>
> </saml2:AttributeStatement>
> 

That AttributeValue looks perfectly fine, should not cause any error
like this.



> Removing this part (before signing) works fine:
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:type="xs:integer"


Ok.  The code is correctly populating the exclusive c14n Transform with
the inclusive prefix, based on what you sent:

> <ds:Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
> <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#";
> PrefixList="xs"/>
> </ds:Transform>


This behavior has changed in 2.4.0.  Previously it populated every
in-scope namespace prefix.  Now it only populates the ones which are
non-visibly used.



> 
> The AttributeValue generation code looks like this:
>         private XSInteger makeAttributeValue(Integer value) {
>                 XSIntegerBuilder integerBuilder =
> (XSIntegerBuilder)builderFactory.getBuilder(XSInteger.TYPE_NAME);
>                 XSInteger intValue =
> integerBuilder.buildObject(AttributeValue.DEFAULT_ELEMENT_NAME,
> XSInteger.TYPE_NAME);
>                 intValue.setValue(value);
>                 return intValue;
>         }       



That also looks fine.