From: "Michael Gerber" <gerbermichi(a)me.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Tuesday, February 3, 2015 10:16:57 AM Subject: Re: [keycloak-dev] Looking for a workaround... Hi All, I've seen that both bugs have the Fix Version 1.1.1.Final, that's great. Do you already know the release date for this version?

Best Michael Am 02. Februar 2015 um 09:32 schrieb Michael Gerber <gerbermichi(a)me.com&gt;: Am 02. Februar 2015 um 09:07 schrieb Stian Thorgersen <stian(a)redhat.com&gt;: ----- Original Message ----- From: "Michael Gerber" <gerbermichi(a)me.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Sunday, 1 February, 2015 4:09:35 PM Subject: Re: [keycloak-dev] Looking for a workaround... I would look at the following scenario: A user starts with the login process and then takes a long break (15 mins or more) without locking his computer. Is this not a relatively uncommon use-case? Would a error message with a link back to the application be a good enough solution?   Unfortunately, it isn't. We have got customers which use one computer for multiple users. And this users are used to logout from the application without closing the browser. The new user then uses the same browser to login. And this action would lead to an error, which is for the user not understandable. There are critical processes like password changes, which should definitely expires after a view minutes and others like authentication which does not matter if they don’t expire during this break. As above we need to improve the error page in this case. With a way back to the application as well. critical actions: - OAUTH_GRANT - CODE_TO_TOKEN (already seperate) - VERIFY_EMAIL - RECOVER_PASSWORD - UPDATE_PROFILE - CONFIGURE_TOTP - UPDATE_PASSWORD non-critical actions: - AUTHENTICATE - SOCIAL_CALLBACK > Am 30.01.2015 um 14:25 schrieb Stian Thorgersen <stian(a)redhat.com&gt;: > > What groups would you propose? > > ----- Original Message ----- >> From: "Michael Gerber" <gerbermichi(a)me.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >> Sent: Monday, 26 January, 2015 4:23:49 PM >> Subject: Re: [keycloak-dev] Looking for a workaround... >> >>> ----- Original Message ----- >>>> From: "Michael Gerber" <gerbermichi(a)me.com&gt; >>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> Sent: Monday, January 26, 2015 2:10:59 PM >>>> Subject: Re: [keycloak-dev] Looking for a workaround... >>>> ----- Original Message ----- >>>> From: "Michael Gerber" <gerbermichi(a)me.com&gt; >>>> To: keycloak-dev(a)lists.jboss.org >>>> >>>> Sent: Monday, January 26, 2015 1:37:53 PM >>>> Subject: [keycloak-dev] Looking for a workaround... >>>> Hi all, >>>> I receive a lot of bug reports from our test team because of the >>>> following >>>> two issues: >>>> - Reset password leads to 400 Bad Request ( >>>> https://issues.jboss.org/browse/KEYCLOAK-1014 ) >>>> This is a tricky one - we can't ignore the state variable as that would >>>> make >>>> it vulnerable. >>>> We could probably come up with an alternative way to generate and verify >>>> state variable though. Could be a HMAC for example. >>>> So you would remove the state cookie? >>> >>> It could potentially be a solution - I started a separate thread on >>> keycloak-dev to discuss this. >>> >>>> - Login attempt after "Login user action lifespan" leads to "Invalid >>>> username >>>> or password." ( https://issues.jboss.org/browse/KEYCLOAK-1015 ) >>>> I agree that the error message is not very good, but I disagree with >>>> removing >>>> the expiration. Why not increase it to say 30 min? That's probably a >>>> more >>>> sensible timeout for reset password as well. >>>> I prefer an expiration of 5 min for the password update process, but >>>> thats >>>> a >>>> bit short for the authentication or password reset process. >>>> I think the best solution would be different expiration times for the >>>> different processes, wouldn't it? >>> >>> Maybe - we do try to keep configuration options to a minimum as these >>> introduce complexity as well as potentials for bug/security issues. >> >> I totaly understand that. >> You have currently the following actions: >> OAUTH_GRANT, >> CODE_TO_TOKEN, >> VERIFY_EMAIL, >> UPDATE_PROFILE, >> CONFIGURE_TOTP, >> UPDATE_PASSWORD, >> RECOVER_PASSWORD, >> AUTHENTICATE, >> SOCIAL_CALLBACK >> >> And it doesn't make sense to have a different conffiguration for every >> one... >> But maybe we can group it into different groups? >> >>> >>> >>>> Do you have any good ideas for a workaround? >>>> Best >>>> Michael >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>