<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"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></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>
> The credential API for users needs to change. Here are the types of<br>
> credentials and how system interacts:<br>
><br>
> 1. Creds stored, gathered, and validated by Keycloak OOTB code.<br>
><br>
> 2. Creds stored in external store, but gathered and validated by<br>
> Keycloak OOTB code. (i.e. User Storage SPI returns the credentials<br>
> directly)<br>
><br>
> 3. Creds gathered by built-in Keycloak OOTB code, but stored and<br>
> validated externally (i.e. LDAP).<br>
><br>
> 4. Creds gathered by custom Authenticators, stored and validated externally.<br>
><br>
> 5. Creds gathered by custom authenticators, stored by keycloak,<br>
> validated by custom code.<br>
><br>
> There's other combinations as well:<br>
><br>
> a. Keycloak stored User, custom credential store<br>
><br>
> b. User Storage Provider, keycloak stored creds<br>
><br>
> c. User Storage Provider, custom credential store<br>
><br>
> Credentials that are validated by Keycloak are currently cached along<br>
> with the user. What sucks about this that some credential types require<br>
> a database update, i.e. HOTP which needs to update a counter. So HOTP<br>
> invalidates the user cache every single login. We also want to allow<br>
> custom credential stores to be able to cache themselves along with the user.<br>
><br>
> What's interesting about #4 is that there really doesn't need to be any<br>
> special SPI. The custom authenticator can lookup the factory and<br>
> typecast it to any interface it wants to to validate the credential.<br>
> Since our caching layer is a local-only (invalidation cache), cachable<br>
> custom externally stored credentials just need a simple.<br>
><br>
> Given all this, gonna put some iterations in on a new credential API.<br>
> Any other thoughts?<br>
><br>
> ______________________________<wbr>_________________<br>
> keycloak-dev mailing list<br>
> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
> <a 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 href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a 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>