Service bus and authentication

Question

I have a system that consists of several applications.

Often these applications need to talk to each other.

Sometimes it can make sense to use a "service account" for the communication but other times it will be necessary to authenticate the request on behalf of the authenticated user.

Because the applications are heterogeneous, it would be difficult to leave to each application the responsibility for the different type of authentications.

Ideally, all applications should be using the same type of authentication.

I am wondering if a service bus, could simplify this integration offering a common authentication at least for service-to-service communication.

Answer 1

I’m going to go on a whim and assume that you’re using some type of web service. Please correct me if I’m wrong.

There are many factors that could play a role in how this “can” be done because there are various ways. Typically with micro service driven architecture, I’ve done what I believe is a simple approach to communication amongst various services.

A messaging bus is a good way to start. In terms of authentication, I would either have a central authority (a service solely responsible for authorization/authentication) or have each service validate a message independent of a central authority (thus eliminating the potential of having a single source of failure).

Central Authority Service

1. Each message published to the bus can have a token or arbitrary string/hash (see JavaScript Web Token) that contains or represents data. Consider passing this as an X-Authorization HEADER value. I’ll leave the security implications out of this answer. Wether you want to store actual data or references to data inside the token (and store the actual data in safer location such as a database) is completely up to you and your business requirements.
2. When a service that’s subscribed to a particular channel receives the message, either by consumption or an API call from your message broker, you can take the authentication/authorization token and make a call to your authority service which will validate the token and return a 200 Okay response or a 401/403 response. It is up to your authority service to decide, validate and make sense of this token according to your business rules.
3. Based on the response returned by the authority service above, the consuming micro service can continue or stop execution. Essentially you’ve created a remote firewall. A JavaScript Web Token contains a signature that’s signed by the initiating service. This can be signed by a private key or even a certificate. Checking the validity of this token or resource is the end goal.

As mentioned above there are many different ways to do this and this is just one of many approaches. Here’s another...

Verifying the authenticity of a message on the service level

Instead of relying on a single point of authority, you could also sign a Token by certificate (Token-signing certificates) or a secret key that’s shared amongst all your consuming micro services. Each micro service will consume the message and check its validity by attempting to decode the signature (by verifying the certificate or using the private key, hopefully tucked away in an environment somewhere and not in code) in the message prior to consuming it and carrying out the micro service’s respective role. This is similar to the method above minus the need for a central authority. There are drawbacks to this method though.

• Whenever you update the code for validating messages, it’ll need to be done on each service consuming messages (imagine having to apply a mission critical security hot-fix to several services in production!)

• Reduces modularization - now your services does more than its intended purpose and has to handle authentication, authorization and carry out its designed functionality

You could also configure your queue service in such a way that your micro services don’t need to be consumers, but rather your broker can fanout or initiate API calls to configured endpoints of your micro services. I personally have not configured my queue services to do this (RabbitMQ / AWS SQS -> Lambda), but a few buddies of mine have.

Hopefully this helps some.