Re^5: Validating XML Signatures / SSL Certificate question (using Net::SAML)

It's different to my own public key however

Is it a different public key or merely a different representation of the same public key? How did you generate the contents of /data/pubkey.pem in the first place?

Good to hear you are making solid progress regardless. My experience of working with SAML has taught me that it is essentially a war of attrition. If you persist you will eventually succeed (although you will curse both the spec designers and the platform implementers before you are through).

Comment on Re^5: Validating XML Signatures / SSL Certificate question (using Net::SAML) Download Code

Replies are listed 'Best First'.
Re^6: Validating XML Signatures / SSL Certificate question (using Net::SAML) by MattP (Novice) on Apr 17, 2017 at 23:38 UTC
Hi Hippo, This is still going on! Currently there seems to be a difference between what is being signed by the NSL team and what the code is expecting - the Net::SAML modules were expecting the assertion node to be signed, we are receiving a signed full XML document. With amended XML (a signed assertion node) we got through the part where XML::Sig was failing - `if ($rsa_pub->verify( $canonical, $bin_signature )) {` - I'm not sure if this is verifying the signature or just the certificate somehow, it's good that it passes now but there are however several steps after this where it fails. It proceeds to perform transforms on the XML before running `if ($digest eq _trim(encode_base64($digest_bin)));` - we're now failing at this point with two completely different strings. Which one of these tests actually verifies the signature I'm not sure, nor why there are these two tests, I don't suppose you have any idea? Either way, getting there (very, very slowly) Cheers, Matt	[reply] [d/l] [select]
Re^7: Validating XML Signatures / SSL Certificate question (using Net::SAML) by hippo (Archbishop) on Sep 08, 2017 at 10:18 UTC
Which one of these tests actually verifies the signature I'm not sure, nor why there are these two tests, I don't suppose you have any idea? The former test verifies that the signature is a valid signature of the dataset by the equivalent private key, so this is the attribution part of the verification if you like. However, since what has actually been signed isn't normally the full SAML request but rather a digest of it you then need the latter test to confirm that the digest is in fact valid for the full SAML request too. If the signature test fails, then either the digest has been monkeyed with or the wrong (impostor?) key has been used. If the signature test passes but the digest fails then someone has amended the XML payload after the signature has been made (or copied a valid signature from some other frame, etc.). Only if both tests pass can you be sure that the entire SAML message is valid. Don't forget to check the timestamps too if you are rolling it yourself.	[reply]