Microservices Architecture – Where to Store Permissions

domain-driven-designobject-orientedpermissionsPHP

We are currently in the process of building a service (a REST API) which is called on by our primary application. The primary application contains a users/permissions/roles set up which is used to verify if the user is able to complete tasks on the application. The user-roles relationship is one-to-many.

The third party API has various end points. We are now required to implement a roles/permissions type system for the endpoints. For example role A might be able to call a create/update endpoint but not destroy.

The question lies within where the roles/permissions should be stored and verified for the REST API service. We already have a roles/permissions set up on the primary application and adding finance specific roles to this set up seems like the wrong choice. It also means that the logic would not be contained on the REST API service so if we were to call the endpoints from other services later down the line this service would also require a roles/permission set up.

The question in general is

Should the roles/permissions tables and logic be stored on the REST API service (the REST API service) – I am almost certain this is the correct/best approach.

How to assign the API services roles/permissions to the users of the primary application. Maybe it requires the set up of additional tables that contain service specific roles (this still feels dirty as we would have two different places where users relate to the roles)

Another option is to have a roles_users table on the REST API service which relates the primary user ID to roles within the service.

Other considerations are that the primary application will need to check these permissions almost every page load to check if certain menu information should be displayed – we can obviously cache this information since it should not be changed often.

The framework is Laravel but I do not think this is relevant to the question. Included it just in case.

Best Answer

Put the permissions and authentication on a separate Auth service.

This checks the username/password and issues a signed token containing all the roles the user is in.

You microservices can then check the signature of the token against the public key and compare the users roles with the required role for the method they are calling.

The benefits of this approach are that

You have a single place which knows about users and roles. If a user needs a new role, or a new user is created you dont have to find each microservice that user will need and add the user to each.
Microservices don't have to call a central place to check roles. The roles are listed in the token which is sent with the request, and they have the public key for the auth service and are thus able to verify that the token isnt fake.
There are a few standard auth flows which use this principle such as O Auth, for which you can download various pre written libraries

Related Solutions

MVC Architecture – Where to Call the ACL Handler

Access control is part of business logic. If you look at use cases, or even user stories, you will see that there are actors involved in any business process. The access control lists are a method to ensure that all and only the actors CAN be involved with the business process.

Access control needs to be supported in the model, the view and the controller.

Access control is part of the model: By limiting the ability to change or view columns or records per the business logic, you necessarily prevent many failures. If only system administrators can change a secondary key field, then it won't be accidentally changed because someone implemented a form incorrectly. Now, I also suggest that you don't specify the restriction as based on "system_administrator" privilege but rather "change_secondary_key" privilege, which system_adminstrators have by design. This separates role from function.

Access control is part of the view. By not enabling form fields to edit data for which the person doesn't have the privileges, you prevent both confusion and errors.

Access control is part of the controller. The controller adjusts the page flow to present only the information appropriate to the user at a time and place that is appropriate.

Certainly, you want to have central management of access controls, on the principle of DNRY (Don't Needlessly Repeat Yourself). Access control is a cross-cutting concern.

Design – DDD, where to use infrastructure services

Question 1

It's ok for the domain service to use infrastructure services, if the infrastructure services accept and return domain concepts - entities and value objects.

In addition, domain services should encapsulate some part of the business logic that can't fit in an entity. So saveUser is not a great method for a domain service.

The question to ask is - is sending an email an important domain concept? Is Email an entity in your domain? If so, you may have an interface for an email sender defined in your domain layer, with a separated implementation in the infrastructure layer, and you could meaningfully do the following in a domain service - :

sendEmailIfWhiteListed(id) {
    Email = this.emailRepository.get(id);
    if (email.isWhiteListed) {
        this.emailSender.send(email);
    }
}

But this is only sensible if emails are entities in your domain. If they are not, then think about - why make sending the email the responsibility of saving the user?

In your case, it doesn't look like emails are entities in your ubiquitous language. So here I favour the domain events pattern. Creating a new user should raise a domain event NewUserCreated, and the handler for the domain event, which I would put in the application layer, would delegate to an email sender to send the email.

Question 2

Who's responsible to convert the post data to a meaningful entity? It depends what you're doing:

If adding a new user
1. If it's simple logic, the application service can call new Entity() and pass in meaningful domain arguments (valueobjects) mapped from the api data argument
2. If it's complex logic, a special domain service called a factory can be used this.entityFactory.Create() and again, pass in meaningful domain arguments (valueobjects) mapped from the api data argument
3. In both cases, the entity or the factory should not be aware of the structure of data as that is an api concern
If updating a user
1. the application service should use a repository to obtain the existing user
2. the user should have methods for updating relevant data. But I'd shy away from CRUD-style methods like user.update - think about why is the user data being updated? DDD encourages us to think about business processes and objectives.
  1. Is the user being updated because it has participated in some business process? Then model the business process explicitly, and have the user data modified as a side effect of the process
  2. Is the user being updated because of a simple CRUD interaction, like editing a profile page? Even so, I'd encourage an entity method like user.UpdateProfile to be explicit about the purpose of the operation.

DDD is ALL about the language - listen to the language used by domain experts, agree on a ubiquitious language, and use it faithfully in your code. If your domain experts don't say persist or save, then don't use those words in your domain layer.