How to restrict access at the entity level in microservices?

Question

Access rights

Sometimes access to specific objects in the system must be restricted or given to specific users or groups.
What is the best way to implement this in microservices?
#1
Should access control, permission management, etc. be the responsibility of the microservice itself? Developers will have to implement permission checks, store and update permissions for each service. This does not seem to be a very reliable and error-prone approach.
#2
Create a specialized microservice to manage access rights to all objects? This service will be called by other microservices to check permissions for each object and filter objects before returning results. Centralized storage and management of permissions is an advantage, but the microservice will have to call the "Permission Service" on each object to check permissions, which can negatively impact performance. And developers will still have to integrate access checks into their services, leaving room for error.
No. 3
Provide access control at the API Gateway or Service Mesh level. You can come up with an implementation that will automatically filter the responses of all services. But in the case where the microservice returns a list, the permissions check must be done for each object. Still a potential performance issue.
Example
Consider the following artificial example. Health care system dealing with test results, x-rays, etc.
Test results should only be available to:

• patient
  
• doctor
  
• laboratories
  

The attending physician may refer the patient to another specialist. The new doctor should also have access to test results. Thus, access can be granted dynamically.
Each object (for example, test results, X-ray image) has a set of rules, which users and groups are allowed to access it.
Imagine that there is a "TestResultsService" microservice that processes test results. Should he be responsible for access control, manage permissions, etc.? Or should access rights management be separated into a separate microservice?
The health system may also process doctor visits. Information about the patient's visit to the doctor should be available:

• patient
  
• doctor
  
• receptionist
  

This is an example of a different type of entity that requires entity-level access restriction for an individual user or group.
It's easy to imagine more examples where entity-level access control is required.

Answer 1

1. Create a common "tree" of entity dependencies (work-flow).
2. Create roles for different objects (users/groups/services, etc.).
3. Create bit-specific ACL "masks" for specific objects and bind them to the desired nodes of the "tree".
4. If you need to manage accesses dynamically: create additional "masks" of accesses (service override ACL) and change them with a specific service.

Answer 2

AAA (Authorization, Authentication, Accounting, I don't mean a family of protocols, but the idea itself) is always a separate heavy service, because high connectivity and dependency of other services are not included in the microservices paradigm.
This approach shows itself best (AWS IAM, Facebook access check, thousands of them): a separate service for working with ACLs, direct access control - on the side of microservices.
You can honestly steal the ACL format from IAM: for each type of object - basic active, owner, read, edit and inherent to this type, all object IDs are in the same format and bijective, records for each type of access are in two forms: Permission - ID (for example, for owner) and Permission - ID List.
Access control directly - on the side of microservices without being moved to separate entities. Access is checked by the ID of the object that initializes the action; if necessary, its groups are also checked.
In your example: PatientTHX1138, DoctorMengl creates a record of visit Case23523 and tests Test991235-991237. Each analysis has the rights to read/modify all of its data (for the patient/his attending physicians) or only the date of admission, office and attending physician (for the receptionist). The case is transferred by a separate function by replacing the owner in the ACL, the previous doctor, depending on the reason for the transfer, either loses access (dismissal / suspension), or gets read access in the usual case of transfer, or gets write access in the case of transfer within the group of doctors. There is a similar situation with different levels of access for doctors and the reception at the visit itself and the patient (the reception hardly needs to know what size the kidney stone is).

Answer 3

I didn’t implement microservices myself, but recently I read about JSON Web Token on Habré, and even on Wikipedia https://ru.wikipedia.org/wiki/JSON_Web_Token
and here’s more about Access + Refresh Token https://habrahabr.ru/company /Voximplant/blog/323160/
meaning that there is a service for authentication and issuance of a token, it encrypts tokens with its secret key (1 access or 2 access + refresh) and issues it to the client, in a simple case, I would write down the user ID and his Role (admin , a regular user), and passed from the client to each microservice that checks it:
-- in 1st of the options it decrypts with a secret key - then each microservice knows about the secret key that the authentication service signed with
-- in the 2nd option, we use asymmetric encryption, i.e. only the authentication service knows the secret, while others will decrypt it without problems (we are less exposed to key leakage if there are many services and we do not trust all of them)
in all cases, the service that the client accesses should not contact the authentication service, which is not slows down the speed.

Answer 4

I came up with the following solution.
This approach has the following features:

1. The ability to uniquely identify each object in the system (eg, UUID) is required.
   
2. Permission synchronization in eventual consistent microservices. In the case of a network partition (partition) between the message broker and the microservice, the permissions will not be synchronized. This can be a problem in the case of revoking permissions. The solution to this problem is a separate issue.