Debugging SAML2 AttributeQuery signature validation failure

o haya ohaya1001 at gmail.com
Fri Feb 13 06:14:50 UTC 2026


FYI, I just got it working!  The main fix was an "ignoreLineBreaks"
setting...

Jim

On Thu, Feb 12, 2026 at 10:17 PM o haya <ohaya1001 at gmail.com> wrote:

> Hi,
>
> My apologies, I forgot to include an example of an AttributeQuery request
> that m app creates:
>
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>   <soap:Body>
>     <saml2p:AttributeQuery
> xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="
> https://idp01.xxx.com:34487/idp/profile/SAML2/SOAP/AttributeQuery"
> ID="id-88c53b43-92dc-484b-80d3-19a09684e813"
> IssueInstant="2026-02-13T03:04:52.763Z" Version="2.0">
>       <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
> https://yyyy01.xxx.com</saml2:Issuer>
>       <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>         <ds:SignedInfo>
>           <ds:CanonicalizationMethod Algorithm="
> http://www.w3.org/2001/10/xml-exc-c14n#"/>
>           <ds:SignatureMethod Algorithm="
> http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
>           <ds:Reference URI="#id-88c53b43-92dc-484b-80d3-19a09684e813">
>             <ds:Transforms>
>               <ds:Transform Algorithm="
> http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
>               <ds:Transform Algorithm="
> http://www.w3.org/2001/10/xml-exc-c14n#"/>
>             </ds:Transforms>
>             <ds:DigestMethod Algorithm="
> http://www.w3.org/2001/04/xmlenc#sha256"/>
>
> <ds:DigestValue>hJyCCUDD2jYOP/ROtzIWYP24rRbz3fPmsVah5A8va8k=</ds:DigestValue>
>           </ds:Reference>
>         </ds:SignedInfo>
>         <ds:SignatureValue>
>
> laKlL3JZg7UnPmYDIcE6mqb0b8vvppb0FpEqT7Mt2Fskx/lQUPZVeotsEghifBsuCbCfFvTJbZ6H
> .
> .
>
> 11fhPYk7hLykLJLggw8VSn9myjDS5tjL9KrwFQxh4OKhFhyHw2a/a0WuAfPMiItOYd74JV6HDMSf
> dNs9ugdwR+sd56Aj8xv9tkEEHXwB+t2BiRhcSQ==
> </ds:SignatureValue>
>         <ds:KeyInfo>
>           <ds:X509Data>
>
> <ds:X509Certificate>MIIDYjCCAkqgAwIBAgIUELCh8lyPXpIIh8oEO8pHhm6JwhwwDQYJKoZIhvcNAQELBQAwOTELMAkG
>
> A1UEBhMCVVMxDDAKBgNVBAoMA0pMTzENMAsGA1UECwwESkxPVTENMAsGA1UEAwwESkxDQTAeFw0y
>
> NjAyMDcwMjQ4NDVaFw0zNjAyMDUwMjQ4NDVaMEsxCzAJBgNVBAYTAlVTMQwwCgYDVQQKDANKTE8x
>
> DTALBgNVBAsMBEpMT1UxHzAdBgNVBAMMFmFya2Nsb2FrMDEtc29hcC1jbGllbnQwggEiMA0GCSqG
> .
> .
> .
>
>
> dWj5dkW7gpaFtoJDLl3d/TvuKHy+oFedACQHvEP8syubMLi3Xjrqo5F6r+yK7JeOXGCpJt8wwkKl
> zkikkohbIQ9hYweRbf0h</ds:X509Certificate>
>           </ds:X509Data>
>         </ds:KeyInfo>
>       </ds:Signature>
>       <saml2:Subject xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
>         <saml2:NameID
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">CN=test5</saml2:NameID>
>       </saml2:Subject>
>       <saml2:Attribute xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
> Name="sn" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
>     </saml2p:AttributeQuery>
>   </soap:Body>
> </soap:Envelope>
>
> On Thu, Feb 12, 2026 at 8:42 PM o haya <ohaya1001 at gmail.com> wrote:
>
>> Hi,
>>
>> I implemented a Java app, "AttributeQueryGenerator.java", that constructs
>> a signed AttributeQuery request, a while ago, and, recently, have been
>> trying to test it with a Shibboleth 5.1.4 IdP, with AttributeQuery enable.
>> The Java app uses OpenSAML 4.
>>
>> It took awhile to get the certs and keys all setup and matched, and I've
>> been able to get test AttributeQuery requests to get processed by the
>> Shibboleth, to the point that Shibboleth attempts to validate the
>> signature, but so far, I have not been able to get the validation working.
>>
>> When I send a request, I gat a SAML response with "RequestDenied",  and,
>> in the idp-process.log file, I get messages that say:
>>
>> WARN  org.apache.xml.security.signature.XMLSignature - Signature
>> verification failed.
>> org.opensaml.xmlsec.signature.support.SignatureException:
>>   Signature cryptographic validation not successful
>> Environment
>>
>>    -
>>
>>    Shibboleth IdP: 5.1.4
>>    -
>>
>>    Profile: SAML2 SOAP AttributeQuery
>>    -
>>
>>    Custom Java client using OpenSAML 4
>>    -
>>
>>    Signing algorithm: RSA-SHA256
>>    -
>>
>>    Digest algorithm: SHA-256
>>    -
>>
>>    Canonicalization: Exclusive C14N (omit comments)
>>    -
>>
>>    Client certificate also used for mTLS
>>
>> What Is Working
>>
>>    -
>>
>>    mTLS succeeds (client cert matches metadata and TLS handshake is
>>    successful).
>>    -
>>
>>    Metadata for the requester entity is loaded correctly (from logs)
>>    -
>>
>>    The IdP resolves the correct SPSSODescriptor and KeyDescriptor from
>>    metadata (from logs)
>>    -
>>
>>    The certificate embedded in request KeyInfo file matches the metadata
>>    certificate (fingerprint and modulus confirmed).
>>    -
>>
>>    At runtime, the private key modulus matches the certificate modulus
>>    (from logs)
>>    -
>>
>>    Local verification inside the generator using Apache Santuario’s
>>    XMLSignature.checkSignatureValue(cert) returns *true*.
>>    -
>>
>>    If I enable the " p:ignoreRequestSignatures="true"" parameter  in the
>>    relying-party.xml, the requests process successfully, and Shibboleth sends
>>    a SAML response with an AttributeStatement with Attribute and
>>    AtttibuteValues (!).
>>
>> What Is Failing
>>
>> The IdP logs show:
>>
>> WARN  org.apache.xml.security.signature.XMLSignature - Signature verification failed.org.opensaml.xmlsec.signature.support.SignatureException:
>>   Signature cryptographic validation not successful
>>
>> This occurs after metadata credential resolution has succeeded, and the
>> correct signing credential is selected.
>>
>> The response returned by the IdP is:
>>
>> StatusCode=RequesterStatusCode=RequestDenied
>>
>> Comments
>>
>> As mentioned, I've checked the certs/keys and matched thumbprints,
>> multiple times, actually, so while I am not 100% sure, I thinkt the failure
>> most probably are due to crypto-related problems
>>
>>    -
>>
>>    Metadata lookup succeeds.
>>    -
>>
>>    A credential is resolved.
>>    -
>>
>>    Signature algorithm is accepted.
>>    -
>>
>>    From logs, the verification seems to be failing during RSA
>>    cryptographic validation.
>>
>> This suggests either:
>>
>>    1.
>>
>>    The data being signed differ from the data being verified
>>    (canonicalization / DOM mutation issue), or
>>    2.
>>
>>    There is something incorrect about ID attribute handling or reference
>>    URI resolution.
>>
>> Generator Structure
>>
>> In the current implementation:
>>
>>    1.
>>
>>    SOAP Envelope DOM is built first.
>>    2.
>>
>>    AttributeQuery is marshalled directly into the SOAP Body.
>>    3.
>>
>>    queryElement.setIdAttributeNS(null, "ID", true) is called.
>>    4.
>>
>>    Signer.signObject(signature) is called.
>>    5.
>>
>>    No DOM moves occur after signing (as far as I have been able to
>>    observe)
>>    6.
>>
>>    The request/document is serialized without pretty-printing.
>>
>> Questions
>>
>>    1.
>>
>>    Are there additional logging categories (in logback) that might help
>>    visibility of:
>>    -
>>
>>       Calculated vs expected digest values?
>>       -
>>
>>       Reference URI resolution details?
>>       -
>>
>>       Canonicalized SignedInfo output?
>>       2.
>>
>>    Is there a recommended way within Shibboleth to dump canonicalized
>>    content used during signature verification?
>>    3.
>>
>>    Are there known problems/gotchas specific to:
>>    -
>>
>>       SOAP AttributeQuery signing
>>       -
>>
>>       ID attribute registration in OpenSAML 4
>>       -
>>
>>       Exclusive C14N handling in mixed SOAP + SAML DOM trees?
>>
>> Any suggestions on any additional debugging techniques that Shibboleth
>> IdP can provide, or any other advice or suggestions, would be GREATLY
>> appreciated, because lately I have spent a ton of time trying to get past
>> the validation :(!!
>>
>> Thanks in advance!!
>>
>> Jim
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20260213/afc9871f/attachment.htm>


More information about the users mailing list