IdP Generating invalid digests?

[Scott Call]

Hello!

I'm building out a new IdP using SimpleSAMLphp and have successfully been able to get it to talk to my AD LDAP backend and to pass authentication and forward that on to the SP.

The problem is that the SP reports a Digest error.

I generated a 2048 RSA key just like the docs said.

After a fair amount of google-fu I came across this method to verify saml:

xmlsec1 verify --id-attr:ID "urn:oasis:names:tc:SAML:2.0:protocol:Response" XMLFILE

The results I get are:
func=xmlSecOpenSSLEvpDigestVerify:file=digests.c:line=250:obj=sha1:subj=unknown:error=12:invalid data:data and digest do not match
FAIL


I also tried with SHA-256 digests (Uncommented the line in saml20-idp-hosted.php).
func=xmlSecOpenSSLEvpDigestVerify:file=digests.c:line=250:obj=sha256:subj=unknown:error=12:invalid data:data and digest do not match
FAIL

Any ideas?

Thanks!
-S

[Peter Schober]

* Scott Call <scott...@gmail.com> [2014-07-23 22:10]:

> The problem is that the SP reports a Digest error.

If SimpleSAMLphp always miscalulcated signature digests others would
have notiecd, I would expect. So I'd be sceptical about that, at
least.

> After a fair amount of google-fu I came across this method to verify saml:
>
> xmlsec1 verify --id-attr:ID "urn:oasis:names:tc:SAML:2.0:protocol:Response"
> XMLFILE

There are many things than can go wrong here, mostly with the XML not
being what has been transmitted verbatim (line breaks, whitespace,
etc.).

What implementation the SAML SP?
-peter

[Scott Call]

On Wednesday, July 23, 2014 3:00:51 PM UTC-7, Peter Schober wrote:

* Scott Call <scott...@gmail.com> [2014-07-23 22:10]:
> The problem is that the SP reports a Digest error.

If SimpleSAMLphp always miscalulcated signature digests others would
have notiecd, I would expect. So I'd be sceptical about that, at
least.

I'm perfectly willing to admit there's a problem with my setup and that simplesamlphp itself is not at fault, it obviously works for others.

I just need a little help figuring out if it's my config/implementation or a borked SP.
 

> After a fair amount of google-fu I came across this method to verify saml:
>
> xmlsec1 verify --id-attr:ID "urn:oasis:names:tc:SAML:2.0:protocol:Response"
> XMLFILE

There are many things than can go wrong here, mostly with the XML not
being what has been transmitted verbatim (line breaks, whitespace,
etc.).

The XML is decoded from the encoded response using the saml2debug module from simpleSAMLphp itself, so hopefully it properly represents the whitespace/etc.

 

What implementation the SAML SP?

It's build into Aspera software's "Console" product.  I will contact them for support but wanted to check and make sure I wasn't doing anything wrong on the IdP side first.

Thanks
-S
 

-peter

[Peter Schober]

* Scott Call <scott...@gmail.com> [2014-07-24 00:11]:

> I just need a little help figuring out if it's my
> config/implementation or a borked SP.

It may just be a mismatch between what your IDP has configured as its
signing key and what key the SP has configured for the IDP.

> The XML is decoded from the encoded response using the saml2debug
> module from simpleSAMLphp itself, so hopefully it properly
> represents the whitespace/etc.

I wouldn't bet on it. At least compare it what the IDP logs on DEBUG.
saml2debug may do different c14n for displaying to a human agent than
what is required/specified in the assertion for example.
Also your testing method might be off (sorry, no suggestions either).

> > What implementation the SAML SP?
>
> It's build into Aspera software's "Console" product. I will contact
> them for support but wanted to check and make sure I wasn't doing
> anything wrong on the IdP side first.

Never heard of that. I still think a misconfigured key on the SP is
more likely, as the message will probably be the same.

If you could check with another implementation (e.g. testshib.org)
you'll at least have some confidence that your deployment is working
fine. Cf.
http://stackoverflow.com/questions/6063158/public-saml-v2-service-providers-for-testing
-peter

[Scott Call]

Thanks for the pointer to testshib (was a whole lot easier than trying to get my force.com sso test working!)

So it looks like the problem is that without any attribute limits, some of the AD attributes are being embedded with illegal characters. 

I put a limit in and it's working with both testshib and Aspera now.
Thanks
-S