5

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?
4
  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.

  • After rereading question 2 it definitely isn't clear. What I'm trying to ask is, messaging service itself doesn't deal with user IDs necessarily. It can just send messages between two things. I guess I'm really trying to understand what "user IDs" that the message service uses should be. Ideally I don't want them to be IDs from the user service since that means you can't use one without the other – Colin M Sep 11 '14 at 22:09
  • Just saw your update. I was wondering if that would be considered an acceptable thing to do (using user ids without really understanding what they are). For that model to work appropriately, however, I'd assume it'd be best to use UUIDs or namespace all identifiers sent to the message service – Colin M Sep 14 '14 at 0:43
  • @ColinMorelli Try searching for "bounded context" from domain-driven design. Since the message service context is isolated from the user service context, it's acceptable/encouraged to use the user id by itself (uuid or otherwise). – Mike Clarke Sep 14 '14 at 19:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.