<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Probably yes. So then maybe we can
      always cache passwords like we do now without an option to disable
      that?<br>
      <br>
      Marek<br>
      <br>
      On 18/08/16 10:55, Stian Thorgersen wrote:<br>
    </div>
    <blockquote
cite="mid:CAJgngAcvDpxOaDysKLgZqHyFxKURjP699NXySPR=znnfyL7pQg@mail.gmail.com"
      type="cite">
      <div dir="ltr">If someone can do a heapdump are we not screwed
        anyways? They can for instance get the realm keys and also
        probably have access to db connection details as well.</div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On 11 August 2016 at 16:39, 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">I wonder
            if we can have UserCredentialValueModel to be more generic<br>
            store? Currently it has properties applicable just to
            password or OTP<br>
            credentials, but it will be better to have something more
            generic based<br>
            on key-value pairs though.<br>
            <br>
            For caching of credentials, should it be made configurable
            if<br>
            credentials are cached or not? Currently the creds from DB
            are always<br>
            cached, which can be an issue for someone in theory (For
            example if<br>
            someone do heapdump of Java process, he might be able to see
            the cached<br>
            credentials).<br>
            <span class="HOEnZb"><font color="#888888"><br>
                Marek<br>
              </font></span>
            <div class="HOEnZb">
              <div class="h5"><br>
                On 10/08/16 17:35, Bill Burke wrote:<br>
                &gt; The credential API for users needs to change.  Here
                are the types of<br>
                &gt; credentials and how system interacts:<br>
                &gt;<br>
                &gt; 1. Creds stored, gathered, and validated by
                Keycloak OOTB code.<br>
                &gt;<br>
                &gt; 2. Creds stored in external store, but gathered and
                validated by<br>
                &gt; Keycloak OOTB code.  (i.e. User Storage SPI returns
                the credentials<br>
                &gt; directly)<br>
                &gt;<br>
                &gt; 3. Creds gathered by built-in Keycloak OOTB code,
                but stored and<br>
                &gt; validated externally (i.e. LDAP).<br>
                &gt;<br>
                &gt; 4. Creds gathered by custom Authenticators, stored
                and validated externally.<br>
                &gt;<br>
                &gt; 5. Creds gathered by custom authenticators, stored
                by keycloak,<br>
                &gt; validated by custom code.<br>
                &gt;<br>
                &gt; There's other combinations as well:<br>
                &gt;<br>
                &gt; a. Keycloak stored User, custom credential store<br>
                &gt;<br>
                &gt; b. User Storage Provider, keycloak stored creds<br>
                &gt;<br>
                &gt; c. User Storage Provider, custom credential store<br>
                &gt;<br>
                &gt; Credentials that are validated by Keycloak are
                currently cached along<br>
                &gt; with the user.  What sucks about this that some
                credential types require<br>
                &gt; a database update, i.e. HOTP which needs to update
                a counter.  So HOTP<br>
                &gt; invalidates the user cache every single login. We
                also want to allow<br>
                &gt; custom credential stores to be able to cache
                themselves along with the user.<br>
                &gt;<br>
                &gt; What's interesting about #4 is that there really
                doesn't need to be any<br>
                &gt; special SPI.  The custom authenticator can lookup
                the factory and<br>
                &gt; typecast it to any interface it wants to to
                validate the credential.<br>
                &gt; Since our caching layer is a local-only
                (invalidation cache), cachable<br>
                &gt; custom externally stored credentials just need a
                simple.<br>
                &gt;<br>
                &gt; Given all this, gonna put some iterations in on a
                new credential API.<br>
                &gt; Any other thoughts?<br>
                &gt;<br>
                &gt; ______________________________<wbr>_________________<br>
                &gt; keycloak-dev mailing list<br>
                &gt; <a moz-do-not-send="true"
                  href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
                &gt; <a moz-do-not-send="true"
                  href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
                  rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/keycloak-dev</a><br>
                <br>
                ______________________________<wbr>_________________<br>
                keycloak-dev mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
                <a moz-do-not-send="true"
                  href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
                  rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/keycloak-dev</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>