<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 25/01/16 10:05, Stian Thorgersen
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAJgngAdRrZxQP-vWx-EdAR14wBGiWhrC78+JpGF_bGkHR8-mPw@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On 25 January 2016 at 09:54, Marek
            Posolda <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div>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.<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I disagree, I really don't see anyone needing to set
              timeouts in second granularity,</div>
          </div>
        </div>
      </div>
    </blockquote>
    Hmm... Don't you think the 90 seconds example is not realistic for
    any deployment?<br>
    <br>
    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.<br>
    <blockquote
cite="mid:CAJgngAdRrZxQP-vWx-EdAR14wBGiWhrC78+JpGF_bGkHR8-mPw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div> <br>
                  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)<br>
                  <br>
                  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):<br>
                  - Delete or disable security-admin-console client<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>We're going to prevent users from deleting internal
              clients and roles, so that won't be a problem anymore</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div> - delete or disable himself<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Can be recovered by adding new user using add-user
              script</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div> - remove roles from himself<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Same as above</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div> - remove scopes from security-admin-console client<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>We haven't covered that one</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div> - configure authentication flow in some way that
                  it's not possible login anymore<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Not covered either</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div> - Timeouts<br>
                  <br>
                  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.<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>What you are saying makes no sense whatsoever. It's
              like saying validation in user interfaces is a waste of
              time.</div>
          </div>
        </div>
      </div>
    </blockquote>
    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.<br>
    <br>
    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.<br>
    <blockquote
cite="mid:CAJgngAdRrZxQP-vWx-EdAR14wBGiWhrC78+JpGF_bGkHR8-mPw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>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.</div>
          </div>
        </div>
      </div>
    </blockquote>
    How about use the confirmation dialog if any timeout is set to
    smaller value than 10 seconds as I mentioned above?<br>
    <br>
    There are likely much more things, which we should handle regarding
    timeouts. And likely disallow some of them. For example:<br>
    - If someone sets "Session Idle timeout" smaller than "Access token
    timeout", the refreshes will be broken. This config should be
    probably restricted<br>
    - 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" )<br>
    <br>
    Marek<br>
    <blockquote
cite="mid:CAJgngAdRrZxQP-vWx-EdAR14wBGiWhrC78+JpGF_bGkHR8-mPw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>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.</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div> <br>
                  Marek<span class=""><br>
                    <br>
                    On 21/01/16 20:45, Stian Thorgersen wrote:<br>
                  </span></div>
                <blockquote type="cite"><span class="">
                    <div dir="ltr">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 <a
                        moz-do-not-send="true"
                        href="https://issues.jboss.org/browse/KEYCLOAK-1341"
                        target="_blank"><a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/KEYCLOAK-1341">https://issues.jboss.org/browse/KEYCLOAK-1341</a></a>)</div>
                    <br>
                    <fieldset></fieldset>
                    <br>
                  </span>
                  <pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
                </blockquote>
                <br>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>