Simplify saml2Login Samples

[jzheaux]

Let's simplify the Boot and JavaConfig saml2Login samples to not sign AuthnRequests.

Let's also simplify their RelyingPartyRegistrationRepository configuration.

[dawi]

I am currently trying to migrate from https://spring.io/projects/spring-security-saml to the new spring security saml integration, but I am getting endless redirects after the IDP login. Now I have seen, this simplification and gave it another try, but I am still facing the endless redirects. Maybe it would be great to provide a minimal Keycloak example as well. :)

[jzheaux]

Hi, @dawi, sorry to hear you're having trouble.

I've recently tested the existing Boot sample against a local Keycloak instance using Spring Security 5.4.1, and I was able to do it without specialized configuration. Because of that, I'm not sure that a new sample will help much.

Two things might help here for your situation, though.

First, endless redirects are usually caused when the relying party errors during authentication and forwards to /error to show the error message. /error, like all endpoints, is protected by default, so Spring Security redirects to Keycloak again. And, because the asserting party knows you're logged in, it redirects back, and the loop restarts. Often, this loop can be broken by adding .antMatchers("/error").permitAll() to your authorizeRequests configuration.

Second, increase your logs org.springframework.security to DEBUG and org.springframework.security.saml2 to TRACE. The additional information may help to see what is failing when your relying party receives a SAML assertion.

[dawi]

Hi @jzheaux, thank you for your quick response. :)

You are right, the redirect loop is caused by forwarding to /error.

The following configuration caused the issue: assertionConsumerServiceLocation("http://localhost:8080/saml/SSO").
As it seems it is not necessary to configure this at all in my scenario.

Where did this value come from? Well, I already had an example based on this one: https://blog.codecentric.de/en/2019/03/secure-spring-boot-app-saml-keycloak. So I downloaded the SAML MetaData from this example and configured the new example to look exactly the same. This example had http://localhost:8080/saml/SSO as AssertionConsumerServiceLocation.

logs with wrong configuration

FilterChainProxy: Securing POST /saml/SSO
SecurityContextPersistenceFilter: Set SecurityContextHolder to empty SecurityContext
CsrfFilter: Invalid CSRF token found for http://localhost:8080/saml/SSO
AccessDeniedHandlerImpl: Responding with 403 status code

logs with correct configuration

FilterChainProxy: Securing POST /login/saml2/sso/demorealm
SecurityContextPersistenceFilter: Set SecurityContextHolder to empty SecurityContext
OpenSamlAuthenticationProvider: Processing SAML response from http://localhost:8081/auth/realms/DemoRealm
OpenSamlAuthenticationProvider: Validating 1 assertions
OpenSamlAuthenticationProvider: Validating assertion ID_63d2e0f3-5f3c-4ea2-adb6-0a8314136116
OpenSamlAuthenticationProvider: Successfully processed SAML Response [ID_b357250a-8d3b-4740-9310-370c5e590681]

Maybe this will help someone who has the same issues. :)

[jzheaux]

Glad you got it working, @dawi.

Correct, unless you are customizing the endpoint where your application wants to receive assertions, setting the assertionConsumerServiceLocation is unnecessary.