Architecture for migrating to Identity and Access Management microservice

Question

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.

Answer 1

Is it advisable to get rid of the user table in my current server altogether and just trust Keycloak's management?

User, as a business entity, usually have much more to it than identity metadata. It is advisable to have your own user or account service with needed API. Because sooner or later, users will have some metadata or settings or functions that are needed for business logic, but play no role in authorization.

As for identity, it is up to the Identity/Login Provider (IDP) implementation. Better use references to business users (IDs) instead of copying user data here. So, a minimal IDP stores only identifiers such as passwords/biometric hashes, mapped to user ids.

Upon verifying, the IDP service can always fetch needed metadata from user (micro)service to fill in an ID token or equivalent with extra user data.

Should users be kept on an independent database?

Preferably closest to the user (micro)service, in its dedicated table/schema/database.

Are there any good rules of thumb and things to keep an eye on when designing these systems?

For Slicing monoliths into micro-services, the major lines are drawn at business capabilities: https://martinfowler.com/articles/microservices.html#OrganizedAroundBusinessCapabilities