[keycloak-dev] in-memory only federated users

[Stian Thorgersen]

IMO this should wait, we have more important things to do right now

On 2 December 2015 at 17:48, Bill Burke <bburke at redhat.com> wrote:

> I'm looking into in-memory only no-import federated users.  What we
> would want to do is allow the UserFederationProvider to create an
> in-memory UserModel and allow for that UserModel to be cached via our
> current architecture.
>
> The current design assumes that all federated users are imported.  This
> includes our caching layer too!  To add to that, the user isn't cached
> until the 2nd request i.e.:
>
> 1. username/password page would hit the UserFederationProvider and the
> user would be imported into Keycloak.  This imported user is not cached,
> only imported into the database for this request's KeycloakSession
> 2. OTP Page or code 2 token would then want to lookup the user by id as
> that is what is stored in the ClientSession.  It would hit the keycloak
> database as it is not cached yet.  This lookup loads the cache for the
> user.
>
> Getting in-memory zero-import to work is even more tricky.  The issue is
> that ClientSession and UserSession need to lookup clients by id.  If the
> user is not in cache, then the cache needs to lookup the user by id
> within storage.  This lookup also needs to happen if a write operation
> is performed on a cache user (getDelegateForUpdate()).  So, Keycloak
> needs to know that that ID is not in local storage and must be looked up
> from a fed provider.  The ID must be formed so that the provider fed
> provider can resolve the lookup.  I could use a URI for the ID i.e.
>
> fed:{providerId}:{login-name}
>
> The problem with this is that this id would need to be larger than 36
> characters which is the current column size for UserEntity.id and any
> other table that references users.   I could possibly do:
>
> fed:{providerAlias}:{login-name}
>
> But its quite possible that combination would be larger than 36
> characters.  We could also just shrink it to:
>
> fed:{login-name}
>
> But then we would have to iterate over every federation provider to find
> and load the user.
>
> So in summary:
> * IDs need to expand from 36 characters to something larger. (255
> maybe).  Don't some DBs have constraints on string primary key size?  DB
> scripts could possibly be
> * CachedUserProvider and UserFederationManager interfaces would need to
> be refactored
> * I don't think UserFederationProvider interface would need to change.
> But users would have to code for in-memory rather than throwing a switch
> to just turn it on.
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> 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/20151202/178c6bf4/attachment.html