[prev in list] [next in list] [prev in thread] [next in thread] 

List:       keycloak-dev
Subject:    [keycloak-dev] porting LDAP to new model
From:       mposolda () redhat ! com (Marek Posolda)
Date:       2016-10-31 8:51:50
Message-ID: 4b5b487d-c977-29ca-d009-00586d97e038 () redhat ! com
[Download RAW message or body]

On 28/10/16 22:45, Bill Burke wrote:
> Was looking at LDAPFederationProvider today and thinking about how it
> would be ported to new model.
>
> * I think it may be possible to re-use most of the code.  The code
> currently assumes that the UserModel is imported into keycloak local
> storage.  What I think we can do is have an in-memory implementation of
> UserModel.  If import is disabled, we create an instance of this pojo.
> This becomes a delegate, and we execute the import logic for mappers.
> Proxy would also be called and just proxy the pojo instance.
>
> * we get rid of the "always read from LDAP" option.  For the new model,
> users will be cached.  If the cache is hit, then the provider is never
> hit.  Since we now have cache policies per UserStorageProvider, I don't
> think its an issue to remove this feature.
+1 for remove "always read from LDAP"

I also wonder about the UNSYNCED usecase (When user is updated in 
Keycloak, changes are saved into Keycloak DB, not to LDAP) . It seems 
that for this particular use-case, users will need to be imported?


Marek
>
> Devil is in the details, but I don't think this will be that bad.  Its
> just a matter of converting things to use the ComponentModel
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



[prev in list] [next in list] [prev in thread] [next in thread]