SOA/Microservices: How to handle authorization in inter-services communications

apiauthorizationmicroservicessoa

Foreground

We are moving from a monolithic platform to a more Service Oriented Architecture. We are applying very basic DDD principles and splitting our domain across different bounded contexts. Each domain is distributed and exposes a service via a web API (REST).

Due to the nature of our business, we have services such as Bookings, Services, Customers, Products, etc.

We have also set up an Identity Server (based on Thinktecture Identity Server 3) whose main role is to:

Centralize authentication (given credentials it issues tokens)
Add claims in the tokens such as: the scopes of the client (as per client I mean the application doing the request), customer identifier (as per customer I mean the person using the application)

We also introduced the role of an API Gateway which centralizes external access to our services. API Gateway provides functionalities which do not require deep knowledge of the internal domains such as:

Reverse proxy: routes incoming requests into the appropriate internal service
Versioning: a version of the API Gateway maps to different versions of the internal services
Authentication: client requests include the token issued by the Identity Server and the API Gateway validates the token (make sure user is who says she is)
Throttling: limit number of requests per client

Authorization

What concerns authorization, this is not managed in the API Gateway but in the internal services itself. We are currently doing 2 main types of authorizations:

Authorization based on client scopes. Example: a client (external application consuming our APIs) requires the scope "bookings" to access the Bookings service API endpoints
Authorization based on the customer. Example: only if a customer (physical person using the application) is a participant of a booking can access the endpoint GET /bookings from the Bookings service

To be able to handle authorization in the internal services, the API Gateway simply forwards the token (when routing the request to the internal service) which includes both information about the client (the application doing the request) and the customer as a claim (in those cases where a person is logged in the client application).

Problem description

So far so good until we introduced inter-service communication (some services can communicate with other services to obtain some data).

Question

How should we approach the authorization in inter-services communications?

Options considered

To discuss the different options I will use the following sample scenario:

We have an external application called ExternalApp that accesses our API (ExternalApp can be seen as the client) in order to build the booking flow
ExternalApp needs access to the Bookings service, hence we grant the ExternalApp the scope "bookings"
Internally (this is something completely transparent for the ExternalApp) the Bookings service acesses the Services service to obtain the default services of a booking such as the flights, the insurances or a car rental

When discussing this issue internally several options popped up, but we are not sure which option is best:

When Bookings communicates with Services, it should simply forward the original token he received from the API Gateway (indicating that the client is the ExternalApp)
- Implications: We might need to grant scopes to the ExternalApp that should not have been granted. Example: ExternalApp might need to have both the scope "bookings" and "services" while only the "bookings" scope could have sufficed
When Bookings communicates with Services, it forwards a token indicating the client now has become Bookings (instead of the ExternalApp) + it adds a claim indicating Bookings is impersonating the original client ExternalApp
- By also including the information that the original client is the ExternalApp the Services service could also do logic such as filtering out some services depending on the original caller (e.g. for internal apps we should return all fights, for external apps only some)
Services should not communicate with each other (so we should not be even be facing this question)

Thanks in advance for your input.

Best Answer

I advise you to have an internal channel of communication between the microservices.

For example to use some message broker like RabbitMQ internally to send/receive or publish/subscribe the messages between microservices.

Then your first end user facing service "in your example the Booking service" will be responsible for validating the token and authorize the customer to do this specific operation may be by communicating with IdentityServer.

Then it will communicate with Services service through Message broker and in that case, there is no need to validate the token again.

I guess this model will be simpler and give you better performance.

Related Solutions

Microservices Security – Authorization Best Practices

No, you are not using tokens correctly.

The idea is that you have an Auth service which issues tokens and Resource services which can validate the token and read the claims it contains. So the rather than forwarding the bearer token to the auth service each time the flow should be as follows

Client -> Auth : please give me a token, here is my username and pass
Auth -> Client : here is a token I have signed it with my private key and it contains the claim "i am an Accounting Agent"

then

Client -> Resource : hi, please give me a list of accounts, here is my token
Resource -> Client : I have checked the signature on your token using the Auth services public key. so I know I can trust your claim that you are an Accounts Agent. Here is the list of accounts

then

Client -> Resource : Please delete this account, here is my token
Resource -> Client : sorry Account Agents are not allowed to delete accounts

This flow prevents the Auth service becoming a performance bottleneck and leave the various microservices to decide if Claim X can do Operation Y

Roles

To address your second question about roles and permissions. At the end of the day a service has to have a set of Roles or Permissions that it knows about. eg you have to actually code something like:

If(users.Role != "RoleX")
{
    return "Access Denied!";
}

Rather than have a whole list of different permissions, 'canEditAccounts' ,' canEditCustomers', 'canDeleteAccounts'... etc etc the modern approach is to instead have a shorter list of Roles 'AccountingAgent' which essentially act as a set of permissions.

If a third party consumes your services though they will have to use the roles that the service knows about. This means that they are stuck with the level of granularity that you provide in your Roles.

ie If your Accounting Agent does too little and your Accounting Manager does too much for your third parties needs you are stuck.

One way around this is to have a dynamic mapping between Roles and Permissions. Have your service know about permissions and query what permissions a role has.

You can then allow your third party consumers to create their own roles, selecting the permissions they want each to have

Security – Authorization and Authentication System for Microservices

Authentication and authorization are always good topics

I will try to explain to you how we deal with authorizations in the current multi-tenant service that I am working. The authentication and authorization are token based, using the JSON Web Token open standard. The service exposes a REST API that any kind of client (web, mobile, and desktop applications) can access. When a user is successfully authenticated the service provides an access token that must be sent on each request to the server.

So let me introduce some concepts we use based on how we perceive and treat data on the server application.

Resource: It is any unit or group of data that a client can access through the service. To all the resources that we want to be controlled we assign a single name. For instance, having the next endpoint rules we can name them as follow:

product

/products
/products/:id

payment

/payments/
/payments/:id

order

/orders
/orders/:id
/orders/:id/products
/orders/:id/products/:id

So let's say that so far we have three resources in our service; product, payment and order.

Action: It is an operation that can be performed on a resource, like, read, create, update, delete, etc. It is not necessary to be just the classic CRUD operations, you can have an action named follow, for instance, if you want to expose a service that propagates some kind of information using WebSockets.

Ability: The ability to perform an action on a resource. For instance; read products, create products, etc. It is basically just a resource/action pair. But you can add a name and description to it too.

Role: A set of abilities that a user can own. For example, a role Cashier could have the abilities "read payment", "create payment" or a role Seller can have the abilities "read product", "read order", "update order", "delete order".

Finally, a user can have various roles assigned to him.

Explanation

As I said before, we use JSON Web Token and the abilities that a user possesses are declared in the payload of the token. So, suppose we have a user with the roles of cashier and seller at the same time, for a small retail store. The payload will look like this:

{
    "scopes": {
        "payment": ["read", "create"],
        "order": ["read", "create", "update", "delete"]
    }
}

As you can see in the scopes claim we don't specify the name of the roles (cashier, seller), instead, just the resources and the actions that are implicated are specified. When a client sends a request to an endpoint, the service should check if the access token contains the resource and action required. For example, a GET request to the endpoint /payments/88 will be successful, but a DELETE request to the same endpoint must fail.

How to group and name the resources and how to define and name the actions and abilities will be a decision made by the developers.

What are the roles and what abilities will have those roles, are decisions made by the customers.

Of course, you must add extra properties to the payload in order to identify the user and the customer (tenant) that issued the token.

{
    "scopes": {
        ...
    },
    "tenant": "acme",
    "user":"coyote"
}

With this method, you can fine-tune the access of any user account to your service. And the most important, you don't have to create various predefined and static roles, like Admin, Agents, and End-Users as you point out in your question. A Super User will be a user that owns a role with all the resources and actions of the service assigned to it.

Now, What if there are 100 resources and we want a role that gives access to all or almost all of them?. Our token payload would be huge. That is solved by nesting the resources and just adding the parent resource in the access token scope.

Authorization is a complicated topic that must be addressed depending on the needs of each application.

Best Answer

Related Solutions

Microservices Security – Authorization Best Practices

Security – Authorization and Authentication System for Microservices

Explanation

Related Topic