[keycloak-dev] in-memory only federated users

[Stian Thorgersen]

On 2 December 2015 at 18:37, Thomas Raehalme <
thomas.raehalme at aitiofinland.com> wrote:

> I think it would also help if you could limit which users are imported
> when synchronizing with LDAP.
>
> If only a small number of enterprise users are going to use the
> application(s) it doesn't make sense to synchronize them all (could be tens
> of thousands in total).
>
I think you can already do that, just don't setup the sync and it will pull
in users only when they login

> Best regards,
> Thomas
> On Dec 2, 2015 7:33 PM, "Bill Burke" <bburke at redhat.com> wrote:
>
>> Some are balking at importing every user when doing federation with
>> backends like ldap even though only minimal import is needed (i.e.
>> username/providerID).
>>
>> On 12/2/2015 12:27 PM, Scott Rossillo wrote:
>> > What problem does this solve? It seems like an uncommon use case.
>> >
>> >
>> > Scott Rossillo
>> > Smartling | Senior Software Engineer
>> > srossillo at smartling.com <mailto:srossillo at smartling.com>
>> >
>> >
>> >> On Dec 2, 2015, at 11:48 AM, Bill Burke <bburke at redhat.com
>> >> <mailto: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
>> >
>>
>> --
>> 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
>>
>
> _______________________________________________
> 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/28167607/attachment.html