4:14 p.m.
I have a couple of questions.
1. Does it make sense to create a RefreshableKeycloakSecurityContext with a null
refreshToken? Seems like this defeats the purpose of that object since it is not
refreshable in that state.
2. I’m looking at SpringSecurityRequestAuthenticator/RequestAuthenticator and it
looks like an OAuth token is treated differently than a Bearer token. OAuth Tokens are
validated back against the keycloak server and Bearer tokens are not. Is there a reason
for this? I thought this would be one of the tenants of SSO where I could take a Bearer
token and be logged in on another client. But that doesn’t seem possible if that token
expires and it can’t be refreshed.
3. Is it possible for me to:
a. extend the Keycloak Spring Security adapter to detect a token w/o a refreshToken
b. then go to the keycloak server and get one
c. save the updated RefreshableKeycloakSecurityContext back to the Spring Security
Context.
4. I’m curious why does SpringSecurityRequestAuthenticator.completeBearerAuthentication
add the KeycloakAuthenticationToken to the SecurityContextHolder, but the
SpringSecurityRequestAuthenticator.completeOAuthAuthentication does not? The reason I ask
is essentially by adding to the holder, it’s going to be added to the session by
SpringSecurity in Spring’s SecurityContextPersistenceFilter, which means that Bearer token
will persist across requests. Is that the intention?
--
Christopher Savory
Software Engineer | EdLogics
On 11/4/16, 1:16 AM, "Chris Savory" <chris.savory(a)edlogics.com> wrote:
Stian,
Currently it is both services and a web app. It’s a monolith in its current state.
We have plans to break apart the API services at some point, but that is in the future.
--
Christopher Savory
Software Engineer | EdLogics
From: Stian Thorgersen <sthorger(a)redhat.com>
Reply-To: "stian(a)redhat.com" <stian(a)redhat.com>
Date: Friday, November 4, 2016 at 12:18 AM
To: Chris Savory <chris.savory(a)edlogics.com>
Cc: "keycloak-user(a)lists.jboss.org" <keycloak-user(a)lists.jboss.org>,
Danilo Bonilla <danilo.bonilla(a)edlogics.com>, David Hartfield
<david.hartfield(a)edlogics.com>, Ali Elhajj <ali.elhajj(a)edlogics.com>
Subject: Re: [keycloak-user] Having difficulty logging out in a 2 client scenario
Sounds like the Spring Security Adapter is services and not a web app? If so it
shouldn't deal with logins and logouts at all. It should be configured as a
bearer-only client.
On 1 November 2016 at 00:11, Chris Savory <chris.savory(a)edlogics.com> wrote:
Our application has 2 clients:
1. A Confidential Client that uses the Spring Security Adapter
2. A Public Client that uses the JavaScript Adapter for an Angular SPA app.
Everything between the two is working fine until I try to logout under certain
conditions.
Logout works fine if I first: deep link into a protected page in my app. The
SpringSecurity adapter for client# 1 redirects me to Keycloak. Keycloack then logs me in
and sends me back to my app where my token was issued for client #1. If I logout under
this scenario via the SpringSecurity adapter it works fine.
In Scenario #2 I first hit an Angular page in my app. Then I log in from the JS
Adapter in client #2. Then through a Rest call to my Spring App (which a Bearer token is
passed) a java session is established on Tomcat. When I put some break points in the
Keycloak Adapter classes I can see that the KeycloakToken only contains the token in this
scenario, but not the refresh token. I can also see that the token was issued for client
#2. When I try to logout, the adapter sends a request to Keycloak with an empty
refresh_token and keycloak returns a 400 error, thus nullifying the logout.
I also tried another scenario where use the JS Adapter get the logout URL and logout
directly to Keycloak via “window.location = keycloak.createLogoutUrl({ redirectUri:
“/site-url”) }). This actually logs out the user from all clients (which is what I want),
but the problem here is on the next request to the Spring app I think there is still an
HttpSession alive and I’m running into the check in
SpringSecurityTokenStore.saveAccountInfo where it throws an exception because there is
already an (old) token inside the SecurityContextHolder.
Any advice on how to proceed from either of these two scenarios?
--
Christopher Savory
Software Engineer | EdLogics
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user