[keycloak-dev] Looking for a workaround...

[Stian Thorgersen]

----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> 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?

They'll either be fixed in a 1.1.1.Final release, which would be in a couple weeks, or in 1.2.0.Beta1 if that's ready in a few weeks.

> 
> Best
> Michael
> 
> Am 02. Februar 2015 um 09:32 schrieb Michael Gerber <gerbermichi at me.com>:
> 
> 
> 
> Am 02. Februar 2015 um 09:07 schrieb Stian Thorgersen <stian at redhat.com>:
> 
> 
> 
> ----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> 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 at redhat.com>:
> >
> > What groups would you propose?
> >
> > ----- Original Message -----
> >> From: "Michael Gerber" <gerbermichi at me.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Monday, 26 January, 2015 4:23:49 PM
> >> Subject: Re: [keycloak-dev] Looking for a workaround...
> >>
> >>> ----- Original Message -----
> >>>> From: "Michael Gerber" <gerbermichi at me.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Sent: Monday, January 26, 2015 2:10:59 PM
> >>>> Subject: Re: [keycloak-dev] Looking for a workaround...
> >>>> ----- Original Message -----
> >>>> From: "Michael Gerber" <gerbermichi at me.com>
> >>>> To: keycloak-dev at 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 at lists.jboss.org
> >>>>
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>