[keycloak-dev] rethinking credentials

Bill Burke bburke at redhat.com
Tue Aug 23 09:43:44 EDT 2016


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/8690586d/attachment.html 


More information about the keycloak-dev mailing list