Public API Facade with Micro Services

Question

Consider a micro service infrastructure in which each service is responsible for one set of activities, and exposes a RESTful interface to its functionality. For example, assume a chat application.

We might have one service which is responsible for creating users, and a second service that is responsible for creating messages.

Now, we want to create a public-facing REST interface to the application. Are there any best practices for creating this public facade to the micro services? I'm interested in a couple of things, mainly:

1. Which layer should handle authentication/authorization (if the underlying services - do they share this data or each implement their own auth)
2. Clearly in this application messages are sent from users to users. However the message service can easily be written in such a way to be usable for anything. Should the public proxy be the one to determine the user information and then delegate to a message service?

Answer 1

1. There are two authorization models that are common: trusted subsystems and delegation.

   • Trusted subsystems is an architecture in which the user creation & message creation services trust the API application to perform the user authentication & authorization. In this model, the API application is trusted (via network ACLs, tokens, x509 certificates, etc.) and can interact with both services in an unrestricted capacity.
   • Delegation is an alternative architecture where the API calls the microservice on behalf of the user; in such a model, both the API & the microservices would handle authorization, with the microservices validating both the identity of the API application and the claims of the user making the original request. The API validates that the user is authenticated & authorized to make the request, while the "message" microservice validates that both the application is trusted and the user is authorized to create messages.

   There are tradeoffs between these two approaches; trusted subsystems is an easier architecture easier to implement, but delegation enables more advanced security features. For your application, it is likely much easier to follow the trusted subsystem strategy, so I would strongly consider building authn/authz at the API "facade" (maybe gateway is a better word here?).

2. EDIT: The answer depends heavily on what the message service is doing, and what data is required for it to carry out its duties. If the message service is just routing messages in realtime to websockets, the requirements may be different than if the messages are persisted to a database. In general, though, it's possible that the service interacts with user IDs without being directly coupled to the user service (e.g. storing the messages in a table as sender_id, recipient_id, and message).

Check out this post for more on delegation and traversing layers.