OpenSAML user discussion

[Scott Cantor <>]

> The response above contains an attribute named "EmpUID" which 
> will be used in a single sign on solution.  I merely need to implement
> a SAML receiver that can validate responses, and spit out 
> relevant attributes.

Ok.

> The initial approach I thought of was to use some functions 
> available SAMLPOSTProfile.  More precisely..

No, that's for helping implement a very specific browser profile sequence of
steps, you're better off just handling this directly. Just read in your data
and once you have it in memory or an istream, you use the SAMLResponse
constructor to build and parse the object. If you need an examples, let me
know.

Once you've built the object, you can use the getter methods to look at it,
and you can (in theory) use the SAMLSignedObject interface to verify() it.
But that's complex, you need to think about your trust model and how you
decide what key to use, etc. My code doesn't perform any PKI validation, it
just verifies the signature.

I can point you at bits of Shib that show examples of doing real validation
if you need help with that.

The main thing is that to use verify() you need to use some objects from the
C++ XML-Security library dealing with keys and certs.

> Does this sound about right?  I've already run into an issue 
> with SAMLPOSTProfile::accept.  I pass in the base64 encoded version of
> the above SAML response, and I get an error on the 
> ResponseId, as follows.  As far as I know, the Response is valid.

If your data is actually in base64, you'll still need to do that (I do that
for you in the POST Profile class, but that's not really what that class is
for. I use the Xerces Base64 class, but it's not the easiest or most
forgiving one around.

Anyway, to your problem, the issue is that the response you're parsing is a
SAML 1.0 response, and it is in fact invalid with respect to 1.1 because the
RequestID isn't an NCName. This is a problem. Ordinarily, you could just use
the SAMLConfig.saml_compatibility_mode setting and toggle it to true. That
kicks the library into 1.0 mode.

The problem is that you may end up with problems on the signature end.
Signatures flat out don't work well in SAML 1.0. That was the reason for
most of the changes in 1.1. I did my best to implement signing in 1.0, but I
had to make some assumptions about the way signing was done and I do a lot
of checking for specific transforms. From what I can see, the signature
you're getting is close, but I think it will fail because it's not
specifying exclusive C14N in that transform.

That was probably a little strong on my part, but it is permitted by the 1.1
spec to reject that transform, and so I did. I wasn't trying to even pretend
to interop with signed 1.0 messages either.

I should be able to patch that problem for you, but let's see how far you
get first.

> Any ideas about what I may be doing wrong, or about how I can 
> better tackle the problem?  Either would be *greatly* appreciated :)

Is this a commercial product sending you the message? Otherwise I don't know
why you'd be seeing a 1.0 response. If you can get the sender to switch to
1.1 you'd have an easier time. ;-)

-- Scott