I'm writing a authentication/authorization solution for our microservice architecture setup. The solution will work with human users as well as other services, granting them access to required services/features. Currently I have __IdentityServer4__ and __ASP.NET Identity__ as a one service and a second service __Identity Management__ providing basically CRUD functionality on entities like users, clients, scopes, claims, API resources etc. Those two services share the database, the users created through Identity Management API can login on Identity Server login page.
I personally would keep them separate - mainly because of
two separate development lifecycles, separate teams, etc.
Let's say team is same for both services.
Service with IdentityServer 4 is small, there is almost no development going on.
Are there any other reasons, technical reasons from IS4 point of view, why it should be separated @leastprivilege ?
What about mongodb and IS4? Do you have any production experience with that?
Well - I personally like the fact that the IS application itself has a pretty low attack surface.
Adding more screens (and more DB access) changes that. I like to keep things separate - also from a deployment point of view.
@leastprivilege I know that issue is closed but I don't want to duplicate and I have additional question.
As I understand IS separated application has own database. Should client operate on data in IS server through some dedicated API? Or this things should be done differently?
I'm looking for guidelines which addresses this subject on documentation but I could find it (pity, it could be great addition to the docs). Maybe do you have some links to point me in proper direction?
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
Well - I personally like the fact that the IS application itself has a pretty low attack surface.
Adding more screens (and more DB access) changes that. I like to keep things separate - also from a deployment point of view.