On 11/29/16 1:14 AM, Stian Thorgersen wrote:
On 23 November 2016 at 22:59, Bill Burke <bburke(a)redhat.com
<mailto:bburke@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
the userLocalStorage()
UserProvider.removeStaleFederationLinks()
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.
Case 1: New provider does do import anymore.
1. Deploy the new provider
2. Provider has to have same provider id as the old one
3. Remove the provider in the realm (this will delete linked users)
4. Create new instance of provider
Case 2: New provider doesn't exist
* Remove linked users on boot up
or
* Remove linked users as they are found (this is the current
implementation).
Bill