Ex: Re: which SP when signature validation fails?

[Brent Putman]

On 7/8/23 11:40 PM, Paul B. Henson wrote:
>
> Yeah, assuming not a ridiculous amount of traffic at the time I can do a pretty reasonable correlation based on timestamp and source IP address; looks like this one is actually a post binding, but does include a referrer pointing out the culprit:
>
> 2023-07-08 20:30:59,331 - 10.104.223.125/node04qrx7hxnxj2xt2wc4iz4kcny110466 - WARN [org.apache.xml.security.signature.XMLSignature:883] - Signature verification failed.
>
> 10.104.223.125 - - [08/Jul/2023:20:30:59 -0700] "POST /idp/profile/SAML2/POST/SSO HTTP/1.1" 400 5414"https:// platform.boomi.com/"  "Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0"
>

If it's a POST binding inbound to the IdP and therefore an XML protocol 
message signature, we do log this, but on DEBUG. You can get this on 
DEBUG from 
org.opensaml.saml.common.binding.security.impl.SAMLProtocolMessageXMLSignatureSecurityHandler. 
Look for lines matching the text of this log statement. Here "context 
issuer" would be the entityID of the SP.

log.debug(
      "{} Validation of protocol message signature failed for context 
issuer '{}', message type: {}",
         getLogPrefix(), contextEntityID, msgType);


For the archives, if it's Redirect or POST SimpleSign binding, the 
corresponding logging class will be 
org.opensaml.saml.common.binding.security.impl.BaseSAMLSimpleSignatureSecurityHandler, 
and logs like:

log.warn("{} Validation of request simple signature failed for context 
issuer: {}", getLogPrefix(),
                     contextEntityID);

log.warn("{} Validation of request simple signature failed for derived 
issuer: {}", getLogPrefix(),
                     derivedEntityID);


I don't recollect why in the first case it's DEBUG and in the latter 
case it's WARN.  There might have been a reason that "made sense" at 
the time, but I'd have to read the surrounding code in-depth to sort it 
out.  If we were going to change something, we'd probably bump failures 
in the first case up to WARN.

Thanks,
Brent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230709/fc0227f8/attachment.htm>