[keycloak-dev] Import users from new User Federation

[Stian Thorgersen]

On 19 August 2016 at 15:52, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 8/19/16 2:37 AM, Stian Thorgersen wrote:
>
>
>
> On 18 August 2016 at 20:30, Bill Burke <bburke at redhat.com> wrote:
>
>>
>> On 8/18/16 4:59 AM, Stian Thorgersen wrote:
>> > Bill,
>> >
>> > Are you planing to have an option to allow import of users with the
>> > new user federation SPI? I'm not convinced we should completely remove
>> > this option.
>> >
>>
>> The only callback that does not exist in the new SPI is
>> validateAndProxy().  With the current federation SPI, the developer
>> implements everything themselves for import.  There are no
>> synchronization APIs/SPIs either.
>>
>
> Sounds like we're removing built-in features around synchronization just
> to make the user have to do everything themselves.
>
> I think you misinterpreted me,  The old User Federation SPI forces the
> developer to write all the import code themselves.  The old User Federation
> SPI does not have any synchronization callbacks, methods or interfaces
> other than validateAndProxy(), the logic of which the user has to write
> themselves too.
>
>
>
>
>> > Some use-cases I could imagine:
>> >
>> > * Allow users to authenticate even if LDAP server is down
>> Our current LDAP provider will not work if LDAP is down, even with the
>> import :)
>>
>
> Yes, I know. However, the fact that we don't currently support it doesn't
> mean we shouldn't in the future.
>
> If the user can only be authenticated via LDAP, an offline mode is not
> possible.  In other words, if LDAP does not expose the password of a user
> (so it can be imported), then offline mode is not possible.  It would only
> be possible if the user has logged in at least once, then the validated
> password could be imported.
>
> So, do you still think we should support import/offline mode given all
> this?
>

Offline mode - IMO this makes sense even if it requires the user to have
logged-in once. At the very least it means that a token can be refreshed
when the LDAP server is down.

Import/decommission - this is been requested by many people, from custom
databases as well as LDAP servers. I can see users wanting to migrate over
time, so initially they want to keep users in LDAP or the relational
database, but once all applications has been converted to Keycloak they no
longer need the old stuff and want to decommission. There's probably those
that want a batch import of everything in one go. We should make this as
easy as possible for users to do. For LDAP it should probably be supported
out of the box. With regards to passwords in LDAP we could have an option
to initiate the decommissioning that would give an overview over what users
have been moved and what hasn't. As user authenticate they would be
decommissioned from LDAP. Once all users have migrated the LDAP provider
would be removed. We could have options to send out remainders to remaining
users as well as an option to simply import without password and require
admin or user to reset the password. For relational databases users should
be required to write the logic that can read users from the custom tables
into the UserModel, but not to write the whole logic around decommissioning
and importing users to the Keycloak database.

One more thing - what about read only modes? I.e. shouldn't we have the
option to disable password update, disable profile updates, etc..?


>
>
> Bill
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/02f2958e/attachment.html