Entity-level access restriction in the microservice architecture based on user or group membership

Question

In the systems, there may be data that is restricted in nature. Sometimes access to specific entities should be easily restricted or granted based on user or group membership.

What is the best way to implement this in the microservice architecture?

#1

Should access control, managing permissions etc. be the responsibility of the microserive itself? Developers will have to implement access control, store, and update permissions for every service. Seems like not very robust and error-prone approach.

#2

Create dedicated microservice handling permission management? This service will be called by other microserives to check access permissions for each entity and filtering entities before returning results. Centralized permissions storage and management is an advantage but microservice will have to make a call to "Permission Service" for each entity to check access rights what may have a negative influence on performance. And developers still have to integrate access checks into their services what leaves space for an error.

#3

Make access control responsibility of the API Gateway or Service Mesh. It is possible to think of an implementation that will automatically filter responses of all services. But in the case when the microservice returns list of entities permissions should be checked for each entity. Still a potential performance problem.

Example

Consider the following synthetic example. Healthcare system dealing with test results, X-Ray images etc. Health information is very sensitive and should not be disclosed.

Test results should be available only to:

• patient
• doctor
• laboratory

Attending doctor may send the patient to another specialist. A new doctor should have access to test results too. So access can be granted dynamically.

So each entity (e.g. test results, X-Ray image) has a set of rules what users and groups are allowed to access it.

Imagine there is a microservice called "Test Results Service" dealing with test results. Should it be responsible for access control, manage permissions etc.? Or permissions management should be extracted to separate microservice?

Healthcare system may also handle visits to a doctor. Information about patient's visit to the doctor should be available to:

• patient
• doctor
• clinic receptionist

This is the example of a different entity type that requires entity level access restriction based on user or group membership.

It is easy to imagine even more examples when entity level access control is required.

Answer 1

I came to the following generic solution.

1. ACL security model is used. Each object in the system has associated set of permissions. Permissions defines who and what actions can perform on the object.
2. Microservices are responsible for entity-level authorization and filter objects in responses based on permissions of the objects.
3. Central Access Control Service is responsible for the creation, update, and deletion of permissions for all objects in the system. Access Control Service database is the primary store of objects' permissions.
4. Permissions stored in microservices databases are synchronized with Access Control Service database using event-carried state transfer. Every time, permissions are changed an event is sent to the message broker. Microservices can subscribe to these events to synchronize permissions.
5. API Gateway can be used as the additional protection layer. API Gateway can call Access Control Service directly (RPC) to check response objects' permissions or load recently revoked permissions.

Design features:

1. A way to uniquely identify each object in the system is required (e.g. UUID).
2. Permissions synchronization in microservices are eventual consistent. In case of partitioning between message broker and microservice permissions will not be synchronized. It may be a problem with revocation of the permissions. The solution to this problem is a separate topic.