[keycloak-dev] rethinking credentials

[Stian Thorgersen]

Clients are not modeled as a user now though. They're linked to a user, but
have a separate mechanism to store credentials right?

On 23 August 2016 at 15:43, Bill Burke <bburke at redhat.com> wrote:

> 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160825/e3274706/attachment-0001.html