I've had some growing pains for our IDP. We currently use an open sourced system that requires some upgrades in order to be securely compliant. However, I have enough users that the migration option offered is completely unacceptable (1 month + of downtime).
I developed a script to automatically migrate the users, but the API assigns the users a new ID. I rely upon this ID to map other services (purchases, etc) and I need to ensure that this ID remains the same.
OK. Looks like I've just outgrown this IDP?
Option 1: Change IDP: When I investigate other IDP's such as Auth-0, none offer any option to retain my current user's ID's - Some offer options for linking accounts but no lookup option from this linked ID (which essentially would be my primary ID) -
Option 2: Manually change IDP's with a script. I've investigated changing the ID's manually.. but I feel like it's too risky, not to mention I get heavily varied results.
Option 3: Sunset period - I'm just obfuscating a security issue in this case, and it would require me to keep the outdated security active (not to mention increased costs) for a period of time..
Option 4 - Month downtime, pause registrations/growth - Get this handled. This is a really painful option I'd like to avoid at all costs if possible.
What I'm struggling to discern is what the community does in this situation? Many other resources are tied to this ID, so I cannot simply change it. Is there a "best practice" that I'm missing here? If so, how would you approach this migration problem? I've considered a lookup table between the user ID, and whatever ID we use to identify. This would add a buffer/proxy between whatever IDP I use and the ID itself so this doesn't happen again in the future.
What I want to know is: What is the best practice for migrating databases/IDP's and retaining the user ID?
Thanks!
Considering I was never able to find a response to this question, or a satisfactory answer (and all leads at RedHat etc were dead ends) - I thought I'd update this post about my solution (despite being unable to share it).
In the end, my solution was to develop a script that took advantage of multithreading and concurrency to batch create users using Keycloak's own API. Over 1/2 a million users in under 3 hours. This revealed the next problem: Despite the Keycloak documentation clearly stating that it accepts an ID, it does nothing with this information on create. This is a problem because a legacy tie with the IDP ID meant that changing the ID would break everything.
Consequently, a followup solution was to enable this script to generate a MYSQL script which could be run post-processing to repair the ID's.
We were therefore able to update Keycloak to the latest version and have yet to see any fallout from direct DB manipulation. If you're waiting for keycloak to develop a better migration method: My advice is do not. From what we could determine, we may have been a KC user with one of the highest number of users that we had seen.
Any questions regarding this, I'll be happy to answer. Please feel free to email me.