Re: [keycloak-user] How to logout

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?

----- Original Message ----- From: "Stan Silvert" <ssilvert(a)redhat.com&gt; To: "Ryan Slominski" <ryans(a)jlab.org&gt; Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org&gt; 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&gt; > To: "Ryan Slominski" <ryans(a)jlab.org&gt; > Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org&gt; > 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&gt; >> To: "Ryan Slominski" <ryans(a)jlab.org&gt; >> Cc: "keycloak-user" <keycloak-user(a)lists.jboss.org&gt; >> 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&gt; >>> To: "keycloak-user" <keycloak-user(a)lists.jboss.org&gt; >>> 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...