[keycloak-dev] in-memory only federated users

[Thomas Raehalme]

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).

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151202/b65a10ab/attachment-0001.html