Authorization On Resource Level In Micro-Services Architecture

Question

I need to design an authorization scheme for an application based on micro-services architecture.

I will focus on 3 micro-services to define the problem.

1. API Gateway Service
2. Projects Service - handles project metadata information like (project_id, name, description ...)
3. Billing Service - handles project billing process and saves (project_id, billing_information)

The current authorization model requires RBAC and ACL (Resource based) where each user has defined set of roles (ADMIN, Project Manager, etc) and also there can be a definition of which user can access which project by it's ID (Project Manager X can access projects 1,2 but not 3,4)

Number of questions:

1. Who's responsibility to manage the ACL of the project? which user can access which project? (assuming that you can have a lot of projects)
2. How the authorization should be verified when user tries to access the Project service or the Billing service when supplying a project_id?

Saw some solution suggestions that a centralized micro-service should be added to run this operation and it should propagate it's information to other services for performance reasons (for example if a user wants to fetch all the relevant projects he can see - this will be much faster if the Project service will join the authorization information in his service). This may raise a problem where new ACL objects will be added and the authorization object will start to grow.

Other say that this should be handled on the micro-service level - but then who is eventually responsible for the ACL? if it's the Projects micro-service, so when the billing service needs to authorize - should it call Projects micro-service?

Answer 1

It is really hard to say what would be the best solution but I can propose smth similar to what we used before and it is the combination of centralized user role management plus authorization check on the services itself.

The idea is having a central authentication and authorization service which will provide you user information with roles (an example could be central OAuth2). And on service side you should fetch this information and check if the provided role allowed.

For ACL I think you can keep that information on the resource side (project service) -the users who allowed to access the resource- as it will be specified per project. And again do the second authorization check on the service along with the role check one after other or together.