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

[Michael Gerber]

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
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150202/f4fea3c6/attachment-0001.html