I am currently building a microservice system on the Java Spring Cloud. Some microservices use PostgreSQL and some of them are MongoDB. REST and JMS are used for communication. The plan is to use SSO and OAuth2 for authentication
The problem I am facing is that authorization must be done at the object / object level of the domain. This means that an ACL (Access Control List) is required. The best practice for this type of architecture is to avoid this kind and have rude protection at the application / service level in each microservice, but, unfortunately, this is not possible.
My last idea is to use Spring Security ACLs and have ACL tables in a common database between all microservices. Access to the database will be provided only by the Spring infrastructure or through the Spring api. The database schema looks stable and is unlikely to change. In this case, I would just break the db sharing rule between microservices.
I considered different types of distributed solutions, but left them:
- One microservice with ACL and access to it through relaxation. The problem is that there are too many HTTP calls and performance degradation. I would have to extend the Spring Security ACL to replace db access with rest calls
- ACLs in each microservice for their own entities. It sounds quite reasonable, but imagine a case where some readable entity models are synchronized with some other microservices or with the same entity that exists in different limited contexts (different microservices). ACLs can become truly unmanaged and can become a source of errors.
- One microservice with ACL tables that are synchronized with other microservices as a read model. The problem is that there is no support in Spring Security ACL for MongoDB. I saw some custom solutions on github and yes, this is doable. But ... when creating a new object, I need to create a record in the microservice that owns the ACL, and then it synchronizes asynchronously as a read model for the microservice that owns the object. This does not sound like a simple solution.
- Select an URL-based access control on the API gateway. But I would have to somehow modify the Spring Security ACL. The API gateway must know too much about other services. Access control granularity is associated with granularity of the REST api. Maybe I canβt imagine all the consequences and other problems that will lead to this approach.
- Finally, the shared db solution I mentioned is my favorite. Actually, this was the first one I disqualified because it is a βgeneralβ database. But, having gone through the possibilities, it seemed to me that this is the only work. There is another additional complication in case I would like to use some kind of caching because I will need a distributed cache.
I would really use some tips and opinions on how to approach architecture, because it is really difficult, and a lot can go wrong here.
Many thanks,
Lucas
source share