OpenSAML user discussion

["Bailo, John" <>]

Thanks, Brent!

 

I suspect then that it is because I had to edit the endpoint URI of the SAML XML that was given to me in order to test my servlet.

 

We’re trying to set up a “real world” test now with unmodified SAML from the Federated server.

 

---

From: Brent Putman [mailto:]
Sent: Wednesday, September 24, 2008 12:01 PM
To:
Cc: Bailo, John
Subject: Re: [OpenSAML] RE: Validate Signature Against Certificate

 

The code in the previous message looked ok, btw.  See below.


Bailo, John wrote:

I receive a warning prior to the exception being thrown.   Can you tell me what action I should take?

 

10:34:05,106 WARN  [Reference] Verification failed for URI "#z88…"

This means that your signature really isn't valid.  Specifically, the signed element (SAML Response I think you said - it's whatever the fragment identifier in the URI above points to) has been changed in some way between when it was signed and when you are validating it.  This often happens either in the marshalling and serialization process on the signer's side, or the de-serialization process on the validator's side.  (And if you're using our binding decoder, the latter isn't likely, we know it works correctly).  Note that the addition of any whitespace to the signed document, via pretty printing, etc, will render the signature invalid.

I can't tell you *exactly* what to do, but basically you just need to figure what is causing changes to the document after it is signed.

It might be helpful to turn on debug logging for package org.apache.xml.security, but mostly only if you have similar information for the signing side as well.  There is output there which will tell you the exact canonicalized data (SignedInfo and Reference URI's) over which the digests are being computed.  If you compare to the same signing side data, it can tell you what has been changed in between.

 

 

I also added a SignatureProfileValidator which my SAMLResponse signature passed indicating the signature was SALM formatted correctly.

That's a good thing to do, but doesn't really have anything to do with this problem.  It just validates that the signature conforms to the SAML signature profile, which amongst other things, can prevent certain types of DOS attacks against you if you actually hand a maliciously formed signature to the signature processing library.

CONFIDENTIALITY NOTICE: The information in this Internet email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized.