[keycloak-dev] Sync + federation
Marek Posolda
mposolda at redhat.com
Thu Jul 31 16:38:46 EDT 2014
On 31.7.2014 22:01, Bill Burke wrote:
>
>
> 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.
Ok, it can be part of the LDAP FederationProvider configuration then.
>
>>>
>>>
>>>
>>>> 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.
>
>
Great, will do.
Marek
More information about the keycloak-dev
mailing list