On 23 November 2016 at 22:59, Bill Burke <bburke(a)redhat.com> wrote:
Ok, I added the logic to remove a user with a federation link that
doesn't have a corresponding UserStorageProvider. The question remains:
* Should I automatically convert UserFederationProviderModels to
ComponentsModels that have a user storage provider with the same id?
Yes, wouldn't anything else mess things up for users?
* Should I remove users imported from custom providers in
Liquibase/Model migration scripts?
No, users could have aggregated information in the Keycloak database not
stored in the custom user federation provider.
I'm wondering if I should do this on boot up by invoking a new method on
Just worried this could be a very long action in the case where there
are thousands of imported users.
I really don't follow the logic of deleting users. Makes no sense to me.
On 11/23/16 10:51 AM, Bill Burke wrote:
> Not sure what to do about migration of custom User Fed providers. The
> issue is around imported users as they have a federation link
> specified. What I think I can do is check to see if the provider exists
> for the linked user when queried, if it doesn't remove the user. This
> would slowly remove old linked users. This is the easiest solution.
> I can do something similar to LDAP in which if a UserStorage with same
> provider id exists, then just port it to the new component model. If
> there isn't a similar provider remove all users that are linked. This
> becomes much harder as this isn't as simple as deleting the user from
> the user table. I'll have to port all the queries that are executed
> from JPA to JDBC when a user is removed.
> More work....
> keycloak-dev mailing list
keycloak-dev mailing list