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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev