<div dir="ltr">Clients are not modeled as a user now though. They're linked to a user, but have a separate mechanism to store credentials right?</div><div class="gmail_extra"><br><div class="gmail_quote">On 23 August 2016 at 15:43, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></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">
<p>I'm only thinking about users right now. That in itself is a big
complex problem. Clients are users, so how would they be
different?<br>
</p><div><div class="h5">
<br>
<div>On 8/23/16 7:38 AM, Stian Thorgersen
wrote:<br>
</div>
<blockquote type="cite">
<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>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><font color="#888888"><br>
Marek<br>
</font></span>
<div>
<div>><br>
> Bill<br>
<br>
______________________________<wbr>_________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">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/mailma<wbr>n/listinfo/keycloak-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>