2:27 p.m.
Hi Stan,
If you have multiple applications you can get out-of-sync. If you open application A in
one browser tab, login, and then navigate to application B in another browser tab then
application B is now out of sync with keycloak until you hit a "protected" page.
The problem arises because I use programmatic security instead of declarative security:
https://javaee.github.io/tutorial/security-webtier003.html
And it looks like the Wildfly client adapter doesn't handle users of programmatic
security in that it doesn't detect if a SSO token exists on pages which are not
declaratively protected (actually programmatic security doesn't work at all with the
Keycloak adapter and I am faking it by redirecting users off of a dummy declaratively
protected URL). It might be possible to have a Servlet filter do a check with the
keycloak server on each request, but that would be costly. The JavaScript client has a
huge advantage because it can watch the keycloak cookie presence via a hidden iframe. In
fact, I realize now exposing the confidential client secret in a form client side is not a
good idea. It seems like to do what I want (track SSO state across multiple tabs and
multiple applications) I might have to actually have two "clients" per
application: (1) on the web server side and (2) another on the browser client side. The
browser client side can then detect the actual state of SSO. Or maybe I can have a single
JavaScript client that is shared among multiple server side Keycloak clients and handles
tracking SSO state and provides the information as a service. Maybe this is built-in to
keycloak server itself?
Ryan
----- Original Message -----
From: "Stan Silvert" <ssilvert(a)redhat.com>
To: "Ryan Slominski" <ryans(a)jlab.org>
Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org>
Sent: Wednesday, August 15, 2018 3:02:18 PM
Subject: Re: [keycloak-user] How to logout
Why is your client out of sync with the keycloak server? If you are
building a servlet-based application (JSF, JSP, Struts, etc.), then why
not use the WildFly adapter in the JEE way as described in the Keycloak
documentation? The WildFly Keycloak adapter takes care of all the hard
stuff for you.
On 8/15/2018 9:50 AM, Ryan Slominski wrote:
Hi Stan,
The documentation doesn't mention this, but it seems the logout URL should be a
POST, not a GET request. Is that true?
So, I'm trying to create an HTML logout form with method post and action to the
documented logout URL. The form has a submit button and two hidden fields:
"client_id" and "client_secret". Clicking the submit button results
in the following JSON response from the keycloak server:
{"error":"invalid_request","error_description":"No
refresh token"}
So, I guess I need a third field, something like "refresh_token"? How would I
get a refresh token? Remember I'm using the Wildfly client adapter and in my scenario
the client is out-of-sync with the keycloak server (the user is logged into keycloak, but
not the local client).
Thanks,
Ryan
----- Original Message -----
From: "Stan Silvert" <ssilvert(a)redhat.com>
To: "keycloak-user" <keycloak-user(a)lists.jboss.org>
Sent: Monday, August 13, 2018 7:15:15 PM
Subject: Re: [keycloak-user] How to logout
HttpServletRequest.logout() should not be a no-op. It was implemented a
long time ago:
https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_bro...
If there is an issue with it you should report it in JIRA.
Stan
On 8/13/2018 4:19 PM, Ryan Slominski wrote:
> Hi Keycloak Users,
>
> I'm using the Wildfly client adapter and trying to logout of Keycloak, even if a
client application container doesn't think it is logged in. This is a problem because
login state with Keycloak and login state with JSESSION_ID in servlet container are two
separate things that can get out-of-sync. The documentation says you can logout in one of
two ways:
>
> 1. Call HttpServletRequest.logout()
> 2. Navigate to URL
https://urldefense.proofpoint.com/v2/url?u=http-3A__auth-2Dserver_auth_re...
{realm-name}/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri
>
> See:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.keycloak.org_doc...
>
> The first appears to be a no-op because the Java container itself isn't logged
in, in this case. This does work if the client container is aware that it is logged in,
but doesn't otherwise. The second also doesn't seem to do anything and just
redirects back to redirect_uri. Any tips?
>
> A forceful logout is useful in the scenario when one client (client A) logs into
Keycloak, and a different client (cilent B) wants to forcefully logout as to switch users.
In this scenario client B doesn't think it is logged in because the client adapter is
using container managed security with JSESSIONID, and locally the client isn't logged
in. However if a login was attempted it would succeed automatically without prompting for
a username and password and therefore the user wouldn't get a chance to provide an
alternate username. A switch user ability is useful when users need to login with
separate admin credentials or also in scenarios where a user says "move over and
I'll drive" to a colleague.
>
> Thanks,
>
> Ryan
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...