Hi Keycloak-Dev,
first of all: awesome product, I like it very much; it’s really feature rich!
My current goal/challenge: I have a vaadin-8 application running on WildFly 17. It uses
spring-security (old one..) and I successfully used Keycloak with
JeePreAuthSecurityConfig.
Now, I’m a fan of Keycloak SSO and I want to use the KeycloakRestTemplate. Therefore I
tried to change to Spring-Web-Security with Keycloak. I followed Sebis products-app
(monkey-see-monkey-do) and picket spring-boot-starter-security:2.1.7.RELEASE and the newes
Keycloak-spring-security-adapter:6.0.1.
Running my app on
http://localhost:8081/myContentRoot/myVaadinView , Keycloak kicks in an
redirects me to the Keycloak login. That redirects me to ../myVaadinView/sso/login with
some state parameters. But here the success-story ends: I’m not redirected to
“myVaadinView” as expected, but to “myContentRoot/”, where I am rejected with HTTP-Status
403 ☹
Debugging the whole thing twice (Sebis Spring-boot Tomcat- and my WildFly
Undertow-container), I found org.springframework.security.web.authentication.
SavedRequestAwareAuthenticationSuccessHandler#onAuthenticationSuccess where
Spring-Web-Security tries to find the original request. On WildFly this *always* fails,
because org.keycloak.adapters.OAuthRequestAuthenticator#resolveCode creates a new
HTTP-Session (reqAuthenticator.changeHttpSessionId(true)).
On Tomcat that works (I think this is a bug in Tomcat) because request.getSession(true)
returns the current session, if it exists and is valid
(org.apache.catalina.connector.Request.doGetSession(boolean)).
How could I deal with that? It seems to be a bug or a design problem to get the old
request from the session vs. creating a new one.
Carsten
----------------------------------------------------------------------------------
Faktor Zehn GmbH Sitz der Gesellschaft: Muenchen Registernummer: HRB 242535
Registergericht: Amtsgericht Muenchen
Geschaeftsfuehrung: Dr. Florian Schwandt, Joerg Renger