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.

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

- delete or disable himself

- remove roles from himself

- remove scopes from security-admin-console client

- configure authentication flow in some way that it's not possible login anymore

- 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.

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> https://issues.jboss.org/browse/KEYCLOAK-1341) _______________________________________________ keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev

On 25/01/16 10:05, Stian Thorgersen wrote: On 25 January 2016 at 09:54, Marek Posolda <mposolda(a)redhat.com&gt; 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> > https://issues.jboss.org/browse/KEYCLOAK-1341) > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > >

On 25/01/16 12:01, Stian Thorgersen wrote: On 25 January 2016 at 11:01, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > On 25/01/16 10:05, Stian Thorgersen wrote: > > > > On 25 January 2016 at 09:54, Marek Posolda < <mposolda(a)redhat.com&gt; > mposolda(a)redhat.com&gt; 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? > To much options and flexibility is usually what makes people hate something. I'm pretty sure the choice between 1 or 2 min is more than sufficient. > > 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. > Client login timeout could potentially be smaller than one minute. However, 10 seconds is to short as there will be requests that take more than 10 seconds. So it could be reduced to 30 seconds. However, the difference between 30 seconds and 1 minute has no effect on security. If someone can intercept the code and use within a minute they can do it within 30 seconds as well (even 10 seconds). So 1 minute is as good from a security perspective IMO, but more user friendly than 10 seconds. > > > >> >> 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? > -1 There's just no need for less than 10 seconds so why even have the option. Removing seconds is a really simple fix. Adding validation and additional notifications boxes is more complex. > > 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" ) > Yes, but we can't do everything now. We'll need to introduce proper validation on admin console/endpoints at some stage, but that's for later. This was a simple proposal to remove one pretty disastrous mistake. Ok, I am fine with that if you thing seconds are redundant. We'll see if community has feedback and want to return seconds ;-) Marek > > > 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 listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > >