OpenSAML user discussion

[Brent Putman <>]

Prasanna Krishna wrote:

Hi Brent & SAML experts -
 
The assertion statement that got generated with the code is as follows:
 
The code that generated the above SAML doc is as follows.  Once again pasting it for your ready ref:

The assertion statement just before Signer.signObject is invoked:

All of that looks good to me.  Should probably be said (obviously) that once the document is signed, you need to make sure that it isn't being modified in any way, intentionally or unintentionally, on the signer/sender side, like pretty print formatting, etc.  From the below, that's clearly not your issue, just saying it for the record.

 

The only difference we find is with respect to digest value & signature value which is being set after Signer.signObject(sig) is invoked.

Yeah, that's pretty much what the Signer does, compute the cryptographic values as indicated by:
http://www.w3.org/TR/xmldsig-core/#sec-CoreGeneration

The receiving party who is not using openSAML is trying to verify the digest value even before verifying the signature.

Before they go any further, they should make sure they really understand the validation process straight from the source:
http://www.w3.org/TR/xmldsig-core/#sec-CoreValidation

So they really have to write their own signature validation code?  Their platform/language/environment doesn't afford a known working XML Signature library that they can take advantage of?  That could turn out to be a lot of work.  That is perhaps an understatement.  :-)

 

The steps followed by them are :

 

Again, the final word is the spec.  They should really, really understand that in detail.  The steps you list indicate that they are unclear on some of the basics...  I'll make some comments, but what they are doing appears to be totally out-of-sync with the spec.  They need to do some more homework.

1) Remove the actual Digest Value and Signature Value in the SAML response, (Please note that DigestValue and SignatureValue tags still exist in the SAML)

For one thing, SAML signatures are enclosed in the element that is signed and therefore must use the enveloped signature transform:
http://www.w3.org/TR/xmldsig-core/#sec-EnvelopedSignature
So they need to be excluding the entire ds:Signature element.  More generally, you need to properly dereference the Reference URI and apply the indicated Transforms.  The output of that process is what serves as the input to the Reference digest method algorithm.

2) Canonicalize the SAML after step 1

There's really ultimately 2 canonicalizations going on: of the ds:SignedInfo (mandatory in all Signatures) and of the dereferenced target of the Reference (b/c SAML mandates the Exclusive C14N transform).  So I'm not sure what they're doing, but sounds like it's probably incorrect either way...

3) Run the SHA2 Hash on Canonicalized output

Fine, except I think what they're using as the output (the hash algorithm input) here is totally out-of-whack with the spec.  You can't just make stuff up.

4) Do B64_encode_RFC on the SHA2 Hash value

5) Compare the Digest Value in the original SAML Response with the B64 encoded hash value.

Well, the spec clearly says that the comparisons should be made over the decoded octet (binary) values.  Encodings aren't canonical in general (e.g. whitespace).

 

 

They are having issues with matching the digest values 

Can you please provide info on whether the above steps are correct or require any change.

Those are just some obvious things I can see that are wrong.  This is a very complex operation, esp. all the canonicalization and generalized transform stuff.  There is a reason that there are entire libraries (e.g. Apache XML Security, what we use under the covers) devoted solely or mostly to signing and validation.  Sounds like they are biting off a lot if they are planning on (re-)implementing one themselves.

 

Another related question:  Would any of the above change if Key Info is included.

No, not really.  ds:KeyInfo is a child of ds:Signature and so (at least in the SAML case) is excluded from the Reference digest calc because of the mandatory enveloped signature transform.   It's just a way (in the Signature use case at least) to convey validation key information, but it's only in an advisory way.  You still have to establish trust of the key extracted or otherwise resolved from the KeyInfo.

--Brent