Thanks for the info. So we can actually do either:
- Disable sessionFixation in spring security
- Provide an endpoint (or reuse existing refresh token endpoint), which
will allow to send changed HttpSession ID to keycloak server. There was
very similar request from someone else couple of days before, so
probably it's something we should consider to support.
Anyway, it could be cool if you can share instructions and/or example on
how to integrate Keycloak with Spring security. It's good that it works
with our adapters without need to change something in them.
Thanks!
Marek
On 8.4.2015 01:29, Scott Rossillo wrote:
Marek, yes, I should have mentioned I was using Spring Security,
sorry
about that. We will have some code I can share shortly on how to
integrate Spring Security with the adapter.
That being said, we solved the issue at hand by modifying the Spring
Security configuration. If anyone else is having problems with single
sign-out, the key part to change in the Spring Security configuration
is to disable Spring’s session fixation protection.
This is something that’s on by default in many Spring Security
installs and according to the Spring docs it’s intended to:
"Create a new session for the newly authenticated user if they
already have a session (as a defence against session-fixation
protection attacks), and copies their session attributes across to
the new session."
So in Spring Security config, "sessionFixation().none()” must be set:
protected void configure(HttpSecurity http) throws Exception {
http.sessionFixation().none();
}
Here’s the flow if you don’t disable this:
1. User access Resource Server (Spring Secured)
2. User redirected by Keycloak agent to Keycloak auth server
3. Successful login redirects back to Resource Server
4. Agent creates a session
5. Spring authentication invoked (how depends on integration method
but irrelevant here)
6. Spring - to prevent session fixation - creates a new session,
copying all attributes from Keycloak created session
Because of this, the authentication continues to function. However, on
single sign-out, the Keycloak agent tries to invalidate the wrong
session (Spring deleted it).
Hope that helps. Will be happy to share a full set of findings and a
working Spring configuration once we get things all worked out.
Best,
Scott
On Tue, Apr 7, 2015 at 3:38 AM, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
So you're using spring security? This is quite an important
detail, which you didn't mention before...
Yeah, it depends on the behaviour what Spring security is doing
regarding sessions. You can try our demo applications
customer-portal + product-portal. Those are simple servlet
applications. If you're not seeing issues with them, but still
seeing issue with your spring security app, then we know that the
issue might be related to spring security.
If you manage to have it working with Spring security, it would be
cool if you can share the details here. We had some questions
related to spring security in the past. If you manage to secure
Spring Security with our adapter, it could be good reference for
the future.
Thanks,
Marek
On 3.4.2015 22:22, Scott Rossillo wrote:
> Update on issue 1, Log user out from KC console:
> It appears this is due to Spring security creating a new session
> and migrating data into it but KC knows nothing about this.
> There’s a way to disable this behavior in Spring Security and I’m
> going to take that path. This should be a non-issue.
>
> ~ Scott
>
>
> On Fri, Apr 3, 2015 at 3:21 PM, Scott Rossillo
> <srossillo(a)smartling.com <mailto:srossillo@smartling.com>> wrote:
>
> Ok, so a few followups. Just to be clear, here’s what I’m
> trying to do and the outcomes of each against 1.2.0.Beta1:
>
> 1. (Original scenario) Log user out from KC console (Users >
> [user] Sessions).
> Result: This still fails with the exception,
>
"org.keycloak.adapters.tomcat.CatalinaUserSessionManagement.logoutSession
> Session not present or already invalidated.”
>
> The exception thrown here is an NPE
> as manager.findSession(httpSessionId) failed to find the
> session. Interestingly, the session is still valid and the ID
> passed into the manager is correct. Furthermore, while
> debugging I can see that manager.findSession() looks up the
> session in a hash map. Interestingly, the session id (key) is
> there, but the value (session) is null. Maybe this is a
> Tomcat bug. Using Tomcat 8.0.18, will test with 8.0.21.
>
> 2. (Second scenario) Application logout.
> Documentation 8.10. Logout
>
(
http://docs.jboss.org/keycloak/docs/1.2.0.Beta1/userguide/html/ch08.html#...)
> say you can either call HttpServletRequest.logout() or
> redirect
>
tohttp://auth-server/auth/realms/{realm-name}/tokens/logout?redirect_uri=encodedRedirectUri.
>
> However, you have to do both.
>
> Call only .logout() and the KC token is still valid and user
> can access app with a new session (it will just redirect to
> KC, see KC session is valid and grant access).
>
> Call only auth-server/…/logout and the Tomcat session remains
> valid. I would have thought that calling the auth-server’s
> logout endpoint would broadcast logout events to logged in
> applications, but it doesn’t.
>
> I’ll file a JIRA for the second case and continue
> investigating the first scenario with a newer Tomcat release.
>
> Best,
> Scott
>
>
>
>
>
>
>
>
>
> On Fri, Apr 3, 2015 at 1:42 AM, Marek Posolda
> <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote:
>
> Sure, maybe even easier alternative is to try debugger.
> You can add this to the beginning of
> $TOMCAT_HOME/bin/catalina.sh:
>
> JAVA_OPTS="$JAVA_OPTS
> -agentlib:jdwp=transport=dt_socket,address=5005,server=y,suspend=n"
>
> then start tomcat and then remotely connect to it from
> your IDE. You will need opened IDE with keycloak sources
> though.
>
> I've changed the code to display the exception
> stacktrace, but it will be available in next release (not
> yet in 1.2.0.Beta1 released yesterday)
>
> Marek
>
>
> On 3.4.2015 01:30, Scott Rossillo wrote:
>> Still no luck using Tomcat 8 and Keycloak 1.2.0.Beta1.
>>
>> I will install a custom built agent tomorrow to catch
>> the actual exception to see what's up.
>>
>>
>> On Thursday, April 2, 2015, Scott Rossillo
>> <srossillo(a)smartling.com
>> <mailto:srossillo@smartling.com>> wrote:
>>
>> Hi,
>>
>> Thanks for the reply.
>>
>> I was trying to log a user out from the Keycloak
>> admin console. I will try the redirect method and
>> see if it works.
>>
>> Also, I’m using 1.1.0.Final. I will upgrade to
>> 1.2.0.Beta1 and report if the issue is still occurring.
>>
>> Best,
>> Scott
>>
>> On Thu, Apr 2, 2015 at 10:23 AM, Marek Posolda
>> <mposolda(a)redhat.com> wrote:
>>
>> Hi,
>>
>> I've tried with Apache Tomcat 6.0.35 but wasn't
>> able to reproduce with latest Keycloak
>> 1.2.0.Beta1. Logout works fine for me.
>>
>> How are you doing logout? From the application
>> or from KC admin console? For the tomcat6, the
>> httpServletRequest.logout() method is not yet
>> available, so best for logout from the
>> application is redirecting to Keycloak logout
>> URL similarly like in our demo example:
>>
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/c...
>>
>> You can also enable debug logging, which should
>> show some additional messages in the log by
>> adding this line into
>> $TOMCAT_HOME/conf/logging.properties:
>>
>> org.keycloak.level = FINE
>>
>> Marek
>>
>>
>>
>> On 2.4.2015 01:37, Scott Rossillo wrote:
>>> Hi all,
>>>
>>> I’m running Keycloak 1.1.0-Final in standalone
>>> mode and using Keycloak agents on Tomcat 6 and
>>> Tomcat 8.
>>>
>>> With both agents, whenever I try to log a user
>>> out via the Keycloak server, I see this in the
>>> Tomcat server’s log:
>>>
>>> Apr 01, 2015 7:27:47 PM
>>>
org.keycloak.adapters.tomcat.CatalinaUserSessionManagement
>>> logoutSession
>>> WARN: Session not present or already invalidated.
>>>
>>> The session is still valid and continues to be
>>> valid for some period of time in each of the
>>> Tomcat instances. Anyone know how to fix?
>>>
>>> I was looking at the source and I see this method:
>>>
>>> *
>>>
>>>
>>> *
org.keycloak.adapters.tomcat.CatalinaUserSessionManagement.
>>>
>>> logoutSession()
>>>
>>> I may test loging the actual exception tomorrow
>>> if no one has a clue, but I think it’s probably
>>> the exception is being thrown for some reason
>>> other than the session no longer existing (it
>>> definitely still does).
>>>
>>> Best,
>>> Scott
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>
>
>