Re: [keycloak-user] subflow issue on reset credentials

Hi Max, Thank you again for your help. For the workaround, I created the following credential reset flow: * subflow "subflow" (alternative) inside subflow: * choose user (required) * send Reset Email (required) * Reset Password (required) * script "set end subflow" (required) -> set a note "resetSubFlow" = "done" * At the top, script "check end subflow" (required) -> check if "resetSubFlow"= "done"? If, yes send back authentication success, otherwise authentication failure. With this configuration, you are not able anymore to connect with the back button. What do you think about the security? The draw back is if the user clicks on the back button, he will receive reset password email twice with no working links. Arnault De : Max Allan <max.allan+keycloak(a)surevine.com&gt; Envoyé : mercredi 9 octobre 2019 14:06 À : Arnault BESNARD Cc : keycloak-user(a)lists.jboss.org Objet : Re: subflow issue on reset credentials Hi Arnault, I did some digging and found that with just the alternative flow version of the reset password, it leaves a session "dangling". (Check "Sessions" in the admin console.) Which is why you can use the cookie to login with "back". I don't quite follow what you're doing, but I think there is a risk that you can't terminate the login that was started with the "Choose username" from your workaround. So, you may be able to make it look safe to the user somehow, but "hackers" would still be able to extract the cookie and re-use it to login as another user. You need to somehow cause a logout when the mail is sent. Max On Wed, 9 Oct 2019 at 12:45, Arnault BESNARD <Arnault.BESNARD@b-com.com<mailto:Arnault.BESNARD@b-com.com>> wrote: Hi Max, Many thanks for your reply. My need is to have a dedicated reset credential flow per authenticator. To achieve this, I use the following strategy: *In authentication flow: * Set a note resetCred with script authenticator (ie resetCred="pwd") * Execute the first authenticator (ie login password form) * Set a note resetCred with script authenticator (ie resetCred="auth2") * Execute the second authenticator. * As all authenticator can call reset credential flow, I configured the later like this: * Subform 1 set as alternative (scenario for the first authentication method, ie password lost) * Set script authenticator as required. The script checks the resetCred value (ie resetCred?="pwd") * <do the reset credential scenario for the first authentication> * subform 2 set as alternative (scenario for the second authentication method) * Set script authenticator as required. The script checks the resetCred value * <do the reset credential scenario for the first authentication> and so on... Except the raised issue, it's working perfectly. I'm currently working on a workaround based on additional notes. My idea is to check at the end of the reset credential flow if at least one of the subflow was fully executed. If no, the script will set invalid user. Any other ideas are welcome ;-) Arnault ________________________________ De : Max Allan <max.allan+keycloak@surevine.com<mailto:max.allan%2Bkeycloak@surevine.com>> Envoyé : mardi 8 octobre 2019 19:17 À : Arnault BESNARD; keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org> Objet : Re: subflow issue on reset credentials Hi Arnault, I think with no "alternative" to alternate to or a "required" flow at the top level, you will not "require" anything other than choosing your user to gain a session. (You can use "choose a user" in a flow as a way to login without a password. So at that point in the process the user is logged in, with a login cookie.) I suppose you could consider it like this : you haven't completed all the required steps so the alternative flow hasn't completed yet, so you shouldn't be logged in. Maybe... I don't think this is a bug. But it does do the same for me. This makes me think : If you capture the cookie when using the normal reset process and replay a session with it and gain access to someone else's account, that would be a security bug. I might dig into that later if I have time/energy! Why would you want all the steps to be an "alternative" to reset credentials? You don't even need to try it twice, just enter your email/username and press submit when you see the "mail sent" message, click back. You're in. Max On Tue, 8 Oct 2019 at 16:54, <keycloak-user-request@lists.jboss.org<mailto:keycloak-user-request@lists.jboss.org>> wrote: From: Arnault BESNARD <Arnault.BESNARD@b-com.com<mailto:Arnault.BESNARD@b-com.com>> To: "keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>" <keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>> Cc: Bcc: Date: Tue, 8 Oct 2019 15:41:49 +0000 Subject: [keycloak-user] subflow issue on reset credentials Hi all, I got a very strange Keycloak behaviour on reset credentials. I set my reset credentials flow as follows: * I created a flow called "subflow" and set it as alternative Inside my subflow I created 3 execution providers: * choose user (required) * send Reset Email (required) * Reset Password (required) The authentication flow is the default "browser" flow. Now, I tried the following scenario: * On the login page, click on "forgot password" * Enter a valid email * A message told you that you should receive an email soon. * Click again on "forgot password" * Now, enter any valid user's email belonging to the realm * Again, a message told you that you should receive an email soon. * Now click on the browser back button. * You are connected with the credential belonging to the user's email ! If you create your reset credentials without subform, this scenario doesn't allow you to connect without the email link. Before opening a bug case, can someone confirm he has the same behaviour ? Thanks in advance, Arnault _______________________________________________ keycloak-user mailing list keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user -- Max Allan phone +448454681066 email max.allan@surevine.com<mailto:max.allan@surevine.com> [Surevine 10th Anniversary] Participate | Collaborate | Innovate Surevine Limited, registered in England and Wales with number 06726289. PO Box 1136, Guildford GU1 9ND, UK If you think you have received this message in error, please notify us. -- Max Allan phone +448454681066 email max.allan@surevine.com<mailto:max.allan@surevine.com> [Surevine 10th Anniversary] Participate | Collaborate | Innovate Surevine Limited, registered in England and Wales with number 06726289. PO Box 1136, Guildford GU1 9ND, UK If you think you have received this message in error, please notify us.