[keycloak-dev] Sync + federation

[Bill Burke]

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.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com