This might be quite trivial for some, but I am studying how to migrate from a
monolithic server to a
microservice architecture, starting from the
Identity and Access Management side.
My current server handles its userbase on its own user table with typical username, email and other metadata on it. I am about to re release the server, so right now its database will be empty and migrations/changes of the data schemas should be easier before the deployment. I am trying to foresee what should I focus on improving first.
I am migrating to
Keycloak. It has its own user data storage and it has some functions to connect with previous LDAP services and User Federation systems. These are great, but I am still unclear about the surrounding architecture of the system to support Keycloak.
Is it advisable to get rid of the user table in my current server altogether and just trust Keycloak's management? Is there any justification for storing user directory data in several places?
If just keeping the Keycloak directory is enough, how should the internal resources of the server refer to each user? Using a foreign key on the Keycloak related tables? This assumes the keycloak tables are on the same DB. Should users be kept on an independent database?
Are there any good rules of thumb and things to keep an eye on when designing these systems?
Any comments would be appreciated.