4:01 a.m.
On 25/01/16 10:05, Stian Thorgersen wrote:
On 25 January 2016 at 09:54, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Not sure about that. IMO seconds are good to have more fine
grained timeout values. For example in some deployment the "Access
token timeout" value 1 minute might be too short, but 2 minutes
are too long, so they prefer to use 90 seconds as compromise.
I disagree, I really don't see anyone needing to set timeouts in
second granularity,
Hmm... Don't you think the 90 seconds example is not
realistic for any
deployment?
Another thing is "Client login timeout" . This is limited just by
network performance and doesn't require any action from user. Usually it
will take around 1-2 seconds to complete. So shouldn't we decrease the
current default value 1 minute to something lower (10 seconds?). Having
bigger value theoretically decreases login security as attacker have
more time to exchange stolen code for token.
Also seconds are good for development. For example, I am sometimes
using seconds for testing (IE. setting timeout to 10 seconds to
quickly enforce refresh etc)
Skip seconds to address KEYCLOAK-1341 looks to me like workaround
rather than real solution. The question is if we should address
KEYCLOAK-1341 at all? There are probably many possibilities how
can admin breaks the login to admin console itself or break the
keycloak entirely. Few examples, which come to my mind (there are
likely much more):
- Delete or disable security-admin-console client
We're going to prevent users from deleting internal clients and roles,
so that won't be a problem anymore
- delete or disable himself
Can be recovered by adding new user using add-user script
- remove roles from himself
Same as above
- remove scopes from security-admin-console client
We haven't covered that one
- configure authentication flow in some way that it's not possible
login anymore
Not covered either
- Timeouts
I don't think that we should try to prevent all of these
situations. I didn't see any real support questions related to
this. And for example in linux if you do "rm -rf /home" the system
is broken as well. Isn't this kind of similar? IMO admins should
do backup of database, so they can revert if they accidentally
mis-configure things.
What you are saying makes no sense whatsoever. It's like saying
validation in user interfaces is a waste of time.
I am not saying validation is
lack of time. Agree we should have them.
But IMO validations are not always sufficient and I don't think that we
can handle every "bad" situation. So would recommend people to do backup
of database to prevent mis-configure things.
Also not sure if it's always good approach to restrict functionality
from admin console just to prevent people from break things. Likely yes
in some cases (builtin objects), however in some other it may be better
to use cofirmation warnings (Do you really want to set timeout just to
10 seconds? Do you really want to re-configure browser authentication
flow of master realm? etc). I suppose admins are technical people and
they know what they're doing.
Validation in user interfaces are there to help people, and to prevent
people doing things that will screw things up. This is an really good
example of where lack of validation on inputs allows users to set
stupid values. 1 second timeouts never makes any sense, so why should
we let users set it. It could also be a mistake as someone wanted to
set 1 minute, but selected second by mistake.
How about use the confirmation dialog
if any timeout is set to smaller
value than 10 seconds as I mentioned above?
There are likely much more things, which we should handle regarding
timeouts. And likely disallow some of them. For example:
- If someone sets "Session Idle timeout" smaller than "Access token
timeout", the refreshes will be broken. This config should be probably
restricted
- Same for "Session max lifespan" . Maybe we should prevent people from
set "Session max lifespan" to be shorter than any other timeout at all
(despite "Offline session idle" )
Marek
Arguing against preventing people from screwing things up for
themselves by coming with another example where they can screw things
up is just not good argumentation. We should do as much as we can, and
in this case it's a very simple fix that could prevent a rather
annoying issue.
Marek
On 21/01/16 20:45, Stian Thorgersen wrote:
> Do we need to have seconds at all for token timeouts? Removing
> seconds from token would make it simpler, but also make sure no
> one sets timeouts that are to short (see
> https://issues.jboss.org/browse/KEYCLOAK-1341)
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev