<div dir="ltr">If we're introducing a new credentials SPI should be consider using it for realms and clients as well?<div><br></div><div>Realms currently have a few things, but we soon need to support key rotation which would mean a realm could have more than one keypair at a time</div><div><br></div><div>Clients already have secret or keypair based auth, but will in the future need certs. Then there's also needs for custom authenticators to store credentials.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 August 2016 at 09:31, 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"><span class="">On 16/08/16 22:51, Bill Burke wrote:<br>
><br>
><br>
> On 8/16/16 10:12 AM, Bruno Oliveira wrote:<br>
>> On 2016-08-11, Marek Posolda wrote:<br>
>>> 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>
>> +1 that would be fantastic, if possible.<br>
> A data model that can store any arbitrary key-value pair would require<br>
> a join with RDBMs storage. Should we keep something like<br>
> UsercredValModel, but just add the ability for attributes? Then model<br>
> the API so that it can avoid joins? There's also the issue of data<br>
> migration from the old tables to the new. Since this is users we<br>
> could be talking about tens of thousands of rows.<br>
</span>Yep, maybe we can keep the "old" attributes on the UserCredValModel, so<br>
it's not needed to migrate and most important credential types (<br>
password, OTP) don't need to change anything. Still we can add key-value<br>
for other credential types? Maybe the caching of users and user<br>
credentials also helps with the performance, so the performance<br>
bottleneck of joins won't be so bad (but yes, I know that we need to<br>
limit size of userCache cache, so the same user and his credential may<br>
be still downloaded from underlying DB multiple times...)<br>
<span class="HOEnZb"><font color="#888888"><br>
Marek<br>
</font></span><div class="HOEnZb"><div class="h5">><br>
> Bill<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>