3:27 p.m.
I'm starting to wonder if the Wildfly client adapter is implemented all wrong.
Doesn't it make more sense to have the state maintained in the web browser using the
JavaScript client (since only the browser can really know the state) and then having a
stateless server that uses bearer tokens to determine if web service requests are
authenticated and authorized? There should be no JSESSIONID at all.
----- 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: Friday, August 17, 2018 8:25:53 AM
Subject: Re: [keycloak-user] How to logout
On 8/16/2018 8:41 AM, Ryan Slominski wrote:
I've enabled backchannel logout in the brokered identity
providers, and I've confirmed it keeps all of the brokered identity providers in sync.
For example if I log into my broker 3 IdP and logout of my realm then I'm also logged
out of broker IdP 3. So, backchannel logout seems to work with the link between the realm
and brokered identity providers. However, unless I'm not understanding backchannel
logout, it doesn't affect clients who manage their own session state such as the
Wildfly client adapter, which creates an independent JSESSIONID cookie to store session
state. So right now logging out of application A does destroy the Keycloak token, but if
a login with application B was already established then it remains locally logged in even
after application A is logged out. Is that not how it is supposed to work? If not, how
do I configure a Wildfly client to honor another application's logout?
I would
have to study the code a bit to know the specifics. I'm
guessing that backchannel logout doesn't invalidate the local session as
you suggest. That might be a little too intrusive, though the app
developer could handle it with an HttpSessionListener.
But it seems to me that you should be able to just use isUserInRole()
with each request and then act accordingly. If you log out of
application A then isUserInRole() on application B should always return
false.
----- 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: Thursday, August 16, 2018 7:44:01 AM
Subject: Re: [keycloak-user] How to logout
On 8/15/2018 4:34 PM, Ryan Slominski wrote:
> Two issues:
>
> (1) Wildfly client adapter doesn't detect when a user is logged into Keycloak on
pages in which HttpServletRequest.isUserInRole() method is used to programmatically
determine who sees what until after hitting a declaratively protected (web.xml) page
first. Wildfly client adapter assumes all pages which use isUserInRole are declaratively
protected, but that is not always true (and essentially never true in my case). This
means when jumping from one application to another you lose your SSO.
If you are correct about isUserInRole() then the WildFly adapter needs
to be fixed.
What should happen is that when you logout of application A then the
Keycloak server sends a backchannel logout to application B. At that
point, a call to isUserInRole() from application B should return false.
Do you have backchannel logout working?
> (2) Trying to switch users in an environment where it is unknown whether you are
logged in or not results in surprise logins as the previous account when you really want
to enter new credentials
>
> Essentially all my application pages show something no matter if you are logged in or
not, but if you are logged in you see extra stuff like edit buttons. When working in a
group around a computer and someone asks to switch users (login as admin or move over and
let me show you scenarios) confusion ensues as the application might show the user as not
logged in, but then attempting to login detects existing token and skips login form. Now
user must logout and try again.
>
>
> ----- 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 4:04:03 PM
> Subject: Re: [keycloak-user] How to logout
>
> On 8/15/2018 3:27 PM, Ryan Slominski wrote:
>> 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:
> I don't understand why this matters. If you are not going to a
> protected page in application B then why do you care if you are logged
> into Keycloak?
>
> I guess I'm not understanding your use case.
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__javaee.github.io_tut...
>>
>> 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...
8:34 p.m.
New subject: How to logout
On 8/20/2018 9:27 AM, Ryan Slominski wrote:
I'm starting to wonder if the Wildfly client adapter is
implemented all wrong. Doesn't it make more sense to have the state maintained in the
web browser using the JavaScript client (since only the browser can really know the state)
and then having a stateless server that uses bearer tokens to determine if web service
requests are authenticated and authorized? There should be no JSESSIONID at all.
I
don't think that makes sense. If you want everything handled in the
browser then you can use the javascript adapter.
If you absolutely need to know the Keycloak session state without making
a server request then javascript adapter would be the solution. In that
case, you wouldn't use the WildFly adapter at all.
----- 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: Friday, August 17, 2018 8:25:53 AM
Subject: Re: [keycloak-user] How to logout
On 8/16/2018 8:41 AM, Ryan Slominski wrote:
> I've enabled backchannel logout in the brokered identity providers, and I've
confirmed it keeps all of the brokered identity providers in sync. For example if I log
into my broker 3 IdP and logout of my realm then I'm also logged out of broker IdP 3.
So, backchannel logout seems to work with the link between the realm and brokered identity
providers. However, unless I'm not understanding backchannel logout, it doesn't
affect clients who manage their own session state such as the Wildfly client adapter,
which creates an independent JSESSIONID cookie to store session state. So right now
logging out of application A does destroy the Keycloak token, but if a login with
application B was already established then it remains locally logged in even after
application A is logged out. Is that not how it is supposed to work? If not, how do I
configure a Wildfly client to honor another application's logout?
I would have to study the code a bit to know the specifics. I'm
guessing that backchannel logout doesn't invalidate the local session as
you suggest. That might be a little too intrusive, though the app
developer could handle it with an HttpSessionListener.
But it seems to me that you should be able to just use isUserInRole()
with each request and then act accordingly. If you log out of
application A then isUserInRole() on application B should always return
false.
> ----- 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: Thursday, August 16, 2018 7:44:01 AM
> Subject: Re: [keycloak-user] How to logout
>
> On 8/15/2018 4:34 PM, Ryan Slominski wrote:
>> Two issues:
>>
>> (1) Wildfly client adapter doesn't detect when a user is logged into Keycloak
on pages in which HttpServletRequest.isUserInRole() method is used to programmatically
determine who sees what until after hitting a declaratively protected (web.xml) page
first. Wildfly client adapter assumes all pages which use isUserInRole are declaratively
protected, but that is not always true (and essentially never true in my case). This
means when jumping from one application to another you lose your SSO.
> If you are correct about isUserInRole() then the WildFly adapter needs
> to be fixed.
>
> What should happen is that when you logout of application A then the
> Keycloak server sends a backchannel logout to application B. At that
> point, a call to isUserInRole() from application B should return false.
>
> Do you have backchannel logout working?
>
>> (2) Trying to switch users in an environment where it is unknown whether you are
logged in or not results in surprise logins as the previous account when you really want
to enter new credentials
>>
>> Essentially all my application pages show something no matter if you are logged
in or not, but if you are logged in you see extra stuff like edit buttons. When working
in a group around a computer and someone asks to switch users (login as admin or move over
and let me show you scenarios) confusion ensues as the application might show the user as
not logged in, but then attempting to login detects existing token and skips login form.
Now user must logout and try again.
>>
>>
>> ----- 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 4:04:03 PM
>> Subject: Re: [keycloak-user] How to logout
>>
>> On 8/15/2018 3:27 PM, Ryan Slominski wrote:
>>> 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:
>> I don't understand why this matters. If you are not going to a
>> protected page in application B then why do you care if you are logged
>> into Keycloak?
>>
>> I guess I'm not understanding your use case.
>>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__javaee.github.io_tut...
>>>
>>> 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...
2349
days inactive
2349
days old
1 comments
2 participants
participants (2)
-
Ryan Slominski -
Stan Silvert