Re: [keycloak-dev] Sync + federation

On 7/31/2014 3:00 PM, Marek Posolda wrote: >>> boolean enablePagination; >>> int pageSize; >> Why would these ever need to be configured. Either the provider >> supports pagination or it doesn't. > It's tricky to rely just on implementation though. For example LDAP > implementation generally supports pagination, but some LDAP servers > support it, some are not. But you will use same implementation (aka > LDAPFederationProvider) for both. So I believe that it should be a way > to disable pagination if you are for example on ApacheDS. Also > configuring pageSize might be useful too according to environment? And > for unit test, you usually want to test with small pageSize just to > verify that it works;-) > > Right now, I already have configurable pageSize and each "page" from > LDAP is synced into Keycloak DB in separate transaction. I just don't want the general SPI polluted with implementation details of one adapter.

>> >> >> >>> long fullSyncPeriod; // -1 if periodic fullSync should be >>> disabled >>> long partialSyncPeriod; // -1 if perodic partialSync should be >>> disabled >>> >> Another option is to let the UserFederationProviderFactory handle >> synchronization and be configured through keycloak-server.json. Then >> there is no UI to do and no changes to the SPIs. >> >> Keycloak would have a generic Job scheduler (does it already?) and in >> the UserFederationProviderFactory.init() method it would just schedule >> the appropriate jobs. > Do we want to support the usecase, when you have 2 realms and you want > sync from LDAP on "realm1" each 1 hour and on "realm2" each 5 hours? > Also you may want to use different pageSize for each LDAP server (or you > may have ActiveDirectory on "realm1" which supports pagination and > "ApacheDS" on "realm2" which doesn't etc). In this case generic > configuration in keycloak-server.json won't work though? > It was just an idea... >> >> >>> And for Admin console UI, we can have some common template, which >>> can be >>> added into page of particular Federation Provider. For example on >>> federated-ldap.html or federated-generic.html there can be checkbox on >>> the bottom of the page like "enable synchronization of users" and when >>> people check it, it will display other settings (pagination, period >>> for >>> full/partial sync, button for trigger sync directly from admin >>> console etc). >>> >>> Also not sure how to properly incorporate it into >>> UserFederationProvider >>> API... Actually UserFederationProvider is supposed to be per-session >>> component whenever Sync process may actually use more >>> session/transaction lifecycles. So adding methods for sync directly >>> into >>> UserFederationProvider may not work though... I wonder if we can have >>> method on UserFederationProviderFactory: >>> >>> UserSyncProvider getInstance(KeycloakSessionFactory sessionFactory, >>> UserFederationProviderModel model); >>> >>> And UserSyncProvider being something like this: >>> >>> public interface UserSyncProvider { >>> void syncAllUsers(KeycloakSessionFactory sessionFactory, >>> UserFederationProviderFactory fedFactory, String realmId, >>> UserFederationProviderModel fedModel) >>> void syncChangedUsers(KeycloakSessionFactory sessionFactory, >>> UserFederationProviderFactory fedFactory, String realmId, >>> UserFederationProviderModel fedModel, Date lastSync); >>> } >> >> What is the difference between syncAllUsers() and syncChangedUsers()? >> Is syncAllUsers() an import/sync from LDAP to Keycloak of all users in >> LDAP store? > yes. And likely also checking all "local" users with federation link, > that link is still valid (ie. user wasn't deleted in LDAP, basically > what UserFederationProvider.isValid is doing) and delete if not. > >> Is synchChangedUsers() only a synchronization from LDAP to >> Keycloak of only users that are currently imported into Keycloak? > It will leverage changelogs and sync just those "remote" users, which > were added/updated (or removed if supported, but it's tricky for LDAP as > I mentioned) remotely from the last sync. Ya, those separate methods soound good. > >> >> >> >> Depending on the answers to above questions, maybe >> UserFederationProviderFactory would have the appropriate sync methods >> instead? Then there would be one less interface that needs to be >> implemented. >> >> UserFederationProviderFactory { >> >> void sync(KeycloakSessionFactory sessionFactory, String realmId, >> UserFederationProviderModel model); >> >> } > I am fine with adding the methods directly on the factory. Was also > thinking about it, but wasn't sure if having methods on "factory" class > is not a workaround though;-) > I say put them on factory.