Describe the bug If your SAML Response is signed, spring security wont be able to verify that I did some debugging and discovered that the following class had the problem.

2022-06-23 17:26:52.747 DEBUG 5308 --- [nio-8282-exec-8] o.o.x.s.s.impl.BaseSignatureTrustEngine : Failed to establish trust of KeyInfo-derived credential 2022-06-23 17:26:52.747 DEBUG 5308 --- [nio-8282-exec-8] o.o.x.s.s.impl.BaseSignatureTrustEngine : Failed to verify signature and/or establish trust using any KeyInfo-derived credentials 2022-06-23 17:26:52.747 DEBUG 5308 --- [nio-8282-exec-8] .x.s.s.i.ExplicitKeySignatureTrustEngine : Attempting to verify signature using trusted credentials 2022-06-23 17:26:52.747 DEBUG 5308 --- [nio-8282-exec-8] .x.s.s.i.ExplicitKeySignatureTrustEngine : Failed to verify signature using either KeyInfo-derived or directly trusted credentials

in the following method trustedCredentials is empty that shouldn't have

protected boolean evaluateTrust(@Nonnull Credential untrustedCredential, @Nullable Iterable<Credential> trustedCredentials) throws SecurityException {
    return this.keyTrust.validate(untrustedCredential, trustedCredentials);
}

To Reproduce Steps to reproduce the behavior.

Expected behavior A clear and concise description of what you expected to happen.

Sample

A link to a GitHub repository with a minimal, reproducible sample.

Reports that include a sample will take priority over reports that do not. At times, we may require a sample, so it is good to try and include a sample up front.

Comment From: marcusdacoregio

Hi @miimnoon, thanks for the report.

Can you confirm if the verification works in version < 5.7.1?

Comment From: miimnoon

Hi @marcusdacoregio

I'm pretty sure that it works in 5.6.3. I was using spring boot 2.6.6 (spring security 5.6.3) and it works fine after updating to spring boot 2.7.0 (spring security 5.7.1) It does not work.

Comment From: dhysf

yes. I also meet the issue. Do you know how to fix it ?

Comment From: marcusdacoregio

Hi folks, can you provide a minimal, reproducible sample so we can simulate it on our side?

Comment From: dhysf

yes. I also meet the issue. Do you know how to fix it ?

remove other configure item. keepmetadata is works. spring.security.saml2.relyingparty.registration.okta.assertingparty.metadata-uri=https://{app}.okta.com/app/{xxxx}/sso/saml/metadata

Comment From: dhysf

application.properties spring.security.saml2.relyingparty.registration.okta.identityprovider.entity-id=http://www.okta.com/{appkey} spring.security.saml2.relyingparty.registration.okta.identityprovider.verification.credentials[0].certificate-location=classpath:rp-certificate.crt spring.security.saml2.relyingparty.registration.okta.identityprovider.singlesignon.url=https://trial-{appid}.okta.com/app/trial-{xxx}/{xxx}/sso/saml spring.security.saml2.relyingparty.registration.okta.identityprovider.singlesignon.sign-request=false

java code

`

@AutoConfiguration public class SecurityConfiguration {

@Bean
SecurityFilterChain configure(HttpSecurity http) throws Exception {

    // @formatter:off
    http
        .authorizeHttpRequests(authorize -> authorize
            .mvcMatchers("/favicon.ico").permitAll()
            .anyRequest().authenticated()
        )
        .saml2Login(
                withDefaults()
        )
        .saml2Logout(withDefaults());
    // @formatter:on

    return http.build();
}

} pom.xml: org.springframework.boot spring-boot-starter-parent 2.7.3 `

Comment From: Shabin

I also faced the same issue. I think the issue is with this commit in spring boot. In Saml2RelyingPartyRegistrationConfiguration.AssertingPartyProperties.get(String name, Function<AssertingParty, T> getter) method, value of getAssertingParty is returned if the value in not null. In case of verification, it will be always not null(It is initiated as new Verification() in Saml2RelyingPartyProperties) and hence the verification creds given with identityprovider key will be ignored and fails the signature validation on saml2 response.

So changing the key from identityprovider to assertingparty works fine.

Comment From: jukekxm

Is the issue still being reproduced? I think the above-mentioned commit may have been solved as it was forward-ported.