sp4a1, SubjectConfirmationData/@InResponseTo did not match the valid value: null

[Peter Schober]

Scott Cantor via dev <dev at shibboleth.net> [2026-03-10 16:31 CET]:
> I guess I'll make an executive decision...you can actually poke a test instance of the SP here:

Thanks, I can see the cookie being set there:

  Set-Cookie: __Host-shibsp_req_20f0344d70d9ff9f769293eaf45bad59=_d696f2b0d953f8ca3514085ca6c78f03; HttpOnly; Path=/; SameSite=None; Secure

and it's being returned by the U-A on subsequent requests e.g. to the
web server root:

  Cookie: __Host-shibsp_req_20f0344d70d9ff9f769293eaf45bad59=_d696f2b0d953f8ca3514085ca6c78f03

> Maybe helpful for comparison.

In my own case I still only see the cookie being set with with
MaxAge=-1 when accessing /secure (after clearing out any state in the
browser and not having accessed the server/s over night) and no other
cookies are being set. The value from that cookie (see below) is
what's being looked for (in vain) later on:

GET /secure (with no cookies set/sent) ->

Set-Cookie: __Host-shibsp_req_05bbe9941b697d6416af5a636651774b=_3faf771d5ebc9e49500940344a232922; HttpOnly; Max-Age=-1; Path=/; SameSite=None; Secure
Location: https://my.idp.example.org/idp/profile/SAML2/Redirect/SSO?SAMLRequest=...
  where the SAML request has an AuthnRequest/@ID="_3faf771d5ebc9e49500940344a232922"

That AuthnRequest/@ID value is contained in the Assertion with
ID="_6aba2f6d758d899fcea0b0dd591d4a2a":

<saml2:SubjectConfirmationData
  InResponseTo="_3faf771d5ebc9e49500940344a232922"

The logs are simply stating those same facts (that the cookie is
missing), with all values matching the observed data:

2026-03-11 13:03:41,784 - 127.0.0.1 - DEBUG [net.shibboleth.sp.profile.impl.ProcessCorrelationCookie:157] - Profile Action ProcessCorrelationCookie: No correlation cookie found for state token '05bbe9941b697d6416af5a636651774b'
2026-03-11 13:03:41,787 - 127.0.0.1 - DEBUG [net.shibboleth.sp.profile.impl.SelectRelyingPartyConfiguration:129] - Profile Action SelectRelyingPartyConfiguration: Found relying party configuration localhost for request
2026-03-11 13:03:41,810 - 127.0.0.1 - INFO [org.opensaml.saml.saml2.profile.impl.ValidateAssertions:313] - Profile Action ValidateAssertions: Assertion validation failure(s): [SubjectConfirmationData/@InResponseTo for assertion '_6aba2f6d758d899fcea0b0dd591d4a2a' did not match the valid value: null, No subject confirmation methods were met for assertion with ID '_6aba2f6d758d899fcea0b0dd591d4a2a']
2026-03-11 13:03:41,815 - 127.0.0.1 - INFO [net.shibboleth.idp.saml.saml2.profile.impl.ProcessAssertionsForAuthentication:227] - Profile Action ProcessAssertionsForAuthentication: No valid SAML Assertions suitable for authentication were found

After turning this check off (thanks!)...

  # hub's conf/sp/saml.properties
  sp.saml.checkInResponseTo = false

I now get past this issue:

2026-03-11 13:22:50,843 - 127.0.0.1 - DEBUG [net.shibboleth.sp.profile.impl.ProcessCorrelationCookie:157] - Profile Action ProcessCorrelationCookie: No correlation cookie found for state token 'e6b308f5a0a6f4bab577591d235bbbe6'
2026-03-11 13:22:50,848 - 127.0.0.1 - DEBUG [net.shibboleth.sp.profile.impl.SelectRelyingPartyConfiguration:129] - Profile Action SelectRelyingPartyConfiguration: Found relying party configuration localhost for request
2026-03-11 13:22:50,883 - 127.0.0.1 - DEBUG [net.shibboleth.sp.saml.saml2.profile.impl.ExtractSAMLAttributes:360] - Profile Action ExtractSAMLAttributes: Decoding incoming SAML Attributes and NameID
2026-03-11 13:22:50,883 - 127.0.0.1 - INFO [net.shibboleth.sp.saml.saml2.profile.impl.ExtractSAMLAttributes:456] - Profile Action ExtractSAMLAttributes: No transcoding rule for NameID (Format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient')
2026-03-11 13:22:50,885 - 127.0.0.1 - DEBUG [net.shibboleth.sp.saml.saml2.profile.impl.ExtractSAMLAttributes:400] - Profile Action ExtractSAMLAttributes: Incoming SAML Attributes mapped to attribute IDs: [uid, samlPairwiseID, eduPersonScopedAffiliation, mail, displayName, givenName,eduPersonPrincipalName, sn]
2026-03-11 13:22:50,889 - 127.0.0.1 - DEBUG [net.shibboleth.sp.profile.impl.RecoverPostData:360] - Profile Action RecoverPostData: No recovery cookie for state token e6b308f5a0a6f4ba, skipping POST recovery check
2026-03-11 13:22:50,890 - 127.0.0.1 - DEBUG [net.shibboleth.sp.profile.AbstractTokenConsumerResponseAction:129] - Profile Action PrepareAgentResponse: No AttributeContext or no attributes found

and fail in a different way now. I'll have to return to the
documentation. Syslog/journald/stdout has this to offer for that same
(new, different) failure:

Mar 11 13:22:50 sp4 shibboleth-sp[25577]: [Shibboleth.AttributeConfiguration] - invalid data supplied for session attributes
Mar 11 13:22:50 sp4 shibboleth-sp[25577]: [Shibboleth.Apache] - error processing session attributes for storage/use
Mar 11 13:22:50 sp4 shibboleth-sp[25577]: [Shibboleth.Apache] - Error while processing session attributes for storage. [, target=https://sp4.example.org/Shibboleth.sso/Validate, handlerType=TokenConsumer]

Those latter lines are sounding promising.

Best regards,
-peter