OpenSAML user discussion

["Scott Cantor" <>]

> By interop I mean between .NET and Java web services
> and clients. My .NET client is failing to validate the
> response from a Java server (which uses opensaml)
> because the WSE SecurityInputFilter is trying
> to validate the signature of the element with the id
> id-12374346 however for a SAML Assertion it is
> comparing against the AssertionID and not the wsu:Id.

Let me be blunt so there's no misunderstanding...a lot of these WSS tools
are broken. They don't follow the official WSS and WSS-SAML specs or the
SAML 1.1 spec and they produce invalid XML, your example being an
illustration of that.

Using SAML in WSS requires wrapping it in additional elements and signing
the outer wrapper into the message because WSS has a questionable
requirement that the only permitted ID attributes you can sign are wsu:Ids.
So you can't directly reference an assertion in your WSS signature and any
tool trying to do so is probably outdated.

With respect to your example...

> <Assertion
> AssertionID="c3d50b725586474de4e411e597933763"
> IssueInstant="2005-06-23T15:53:51.125Z"
> Issuer="CN=www.foo.com, OU=Other, OU=PKI, OU=XxX,
> O=U.S. Government, C=US" MajorVersion="1"
> MinorVersion="1" wsu:Id="id-12374346">

That's invalid SAML. The SAML schema does not allow wsu:Id to appear inside
the Assertion element. Any SAML library is free to be overly permissive, but
mine would spit it out, for example (though see my note at the end).

> If these ids contained the same value then I think
> this would work. Does opensaml add the wsu:Id? 

No. Whatever did is broken.

> I know that you can create a SAMLAssertion with an id
> (AssertionID) but for the .Net client to interoperate
> with a Java based service the ids probably need to
> match.

Actually, the wsu:Id simply can't be there, so it's immaterial what it is.
When the WSS layer signs, it's supposed to wrap it in some element, STR
maybe, and then the wsu:Id is inside that. I think. Not my expertise, but
you can trust me on the SAML part.

> I'm saying this because in the request
> generated by the .Net client match and the Java server
> seems to have no problem digesting them and validating
> the signature.

Any tool that accepts an assertion that looks like that is playing with
fire. But my guess is the Java server is just parsing blind, and
mechanically verifying the signature.

In that scenario, OpenSAML would have a hard time detecting the error
because it's probably being handed a pre-parsed DOM, and if it outputs the
same DOM, it wouldn't know to delete the illegal attribute either.

XML kinda blows for protocol stuff.

-- Scott