8:43 a.m.
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?
On 8/23/16 7:38 AM, Stian Thorgersen wrote:
If we're introducing a new credentials SPI should be consider
using it
for realms and clients as well?
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
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.
On 23 August 2016 at 09:31, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
On 16/08/16 22:51, Bill Burke wrote:
>
>
> On 8/16/16 10:12 AM, Bruno Oliveira wrote:
>> On 2016-08-11, Marek Posolda wrote:
>>> I wonder if we can have UserCredentialValueModel to be more
generic
>>> store? Currently it has properties applicable just to password
or OTP
>>> credentials, but it will be better to have something more
generic based
>>> on key-value pairs though.
>> +1 that would be fantastic, if possible.
> A data model that can store any arbitrary key-value pair would
require
> a join with RDBMs storage. Should we keep something like
> UsercredValModel, but just add the ability for attributes? Then
model
> the API so that it can avoid joins? There's also the issue of data
> migration from the old tables to the new. Since this is users we
> could be talking about tens of thousands of rows.
Yep, maybe we can keep the "old" attributes on the
UserCredValModel, so
it's not needed to migrate and most important credential types (
password, OTP) don't need to change anything. Still we can add
key-value
for other credential types? Maybe the caching of users and user
credentials also helps with the performance, so the performance
bottleneck of joins won't be so bad (but yes, I know that we need to
limit size of userCache cache, so the same user and his credential may
be still downloaded from underlying DB multiple times...)
Marek
>
> Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>