[keycloak-dev] code freeze at end of day today

Bill Burke bburke at redhat.com
Mon Aug 4 16:09:13 EDT 2014

On 8/4/2014 4:01 PM, Marek Posolda wrote:
> I've finished testing with AD and added one more commit (support
> registration of new users into some Active Directory deployments).
> Tomorrow, I plan to update docs for export/import but no more commits
> from me (unless I found something critical and I will ping you in that
> case).
> btv. some more feedback and questions from LDAP testing:
> * During import of realm, do we want to add users just to local store or
> also to federation providers? Example: I've exported users from my realm
> and some are mapped to LDAP. Now I want to import them into different
> (clean) database, but during import, they are added into both local
> database and into LDAP where they already exists -> error.
> I wonder if we should skip adding users into FederationProviders at all
> (or at least have it configurable) wdyt?

IMO, Users shouldn't be registered with Federation Provider on an import.

> * The small disadvantage of proxy objects are multiple calls to LDAP
> during single user registration. For example calling to:
>           user.setFirstName(formData.getFirst("firstName"));
>           user.setLastName(formData.getFirst("lastName"));
>           user.setEmail(email);
> will actually perform 6 network calls to LDAP (each method call to
> WritableLDAPUserModelDelegate first checks if user exists and then doing
> full update of user). Do we care about this? LDAP is primarily designed
> for reading, so maybe writing from Keycloak won't be often anyway? I am
> not sure...

Fix for after beta-4.  We can add a addUser(Map<string, string> 
attriutes) method?

> * The semantics of "searchForUser" is a bit different for
> FederationProviders and our model implementations. For example, if you
> have user "John Doe" and you search for "ohn Do" in admin console, then
> both JPA and Mongo local providers will return you "John Doe" as they
> add % at the beginning/end. However federation providers are looking
> exactly for FirstName: "ohn" , LastName: "Do", so if "John Doe" exists
> in LDAP, he won't be returned.

Can we do anything about that?  Does LDAP have a "like"?

Bill Burke
JBoss, a division of Red Hat

More information about the keycloak-dev mailing list