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> 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
https://lists.jboss.org/mailman/listinfo/keycloak-dev