Securing REST microservices with Spring Security

Question

I'm looking for a best-practice and efficient solution to secure multiple microservices communicating via REST to a Web Client application.

Current setup:

These microservices are made in Java, with Spring Framework and run into Docker containers.

The client is an Angular 2 application.

I made a new µService that will act as a "gateway" and be the only communication point between my web client and my other services.

I retrieve a JWT encrypted token from a remote authentication API (let's call it LOCK)

Solution I was thinking about:

I could store the login JWT into a cookie, and send it to the gateway.

The gateway embed in the final payload sent to the concerned µService the token and store the user if it's new into a database.

The microservice then get the query, checks in the remote authentication service the user role, and if it's sufficient, it returns a 200 status with result.

Edit

We will need to have a RabbitMQ Broker into our µServices hive, and thus, to use the WebSockets. In order to secure WebSockets in the same way as securing REST APIs, I'm not sure if we still should manage security in a gateway, and maybe manage it at the microservice level by itself. Because lots of messages will transit, and we should maybe get rid a middleware that will slow down the thing.

Questions:

Is it a good practice ? What could possibly be done better ? Do you have any example of things done that fills the same needs ? Thanks a lot for your shares & thoughts.

Answer 1

I would do this in the following way:

Consider that every microservice is behind the apigateway, even the authentication/authorisation microservice -> let's call it simply auth.

Once the request comes, the apigateway checks with auth service, auth service does what it needs in order to verify that the token and the requester are legit, and responds back to apigateway with a 200/401(/403).

If apigw got a 200, it forwards the request to whatever microservice was at that endpoint, otherwise returns the other statuses.

If we consider this scenario and that the only entry point into your environment it through apigateway, I don't see any reason for you to secure the communication between other services.

Let's consider this scenario:

client -> calls POST /api/v1/cars

1. Between client and apigw we have a secure call because obviously we're gonna be using a certificate... therefore the client will call https://..../api/v1/cars
2. request reaches apigw, it decrypts the request
3. gets the jtw
4. asks auth -> this one return 200
5. forwards the request to CarsMicroservice
6. Cars microservice trusts the request because it knows that someone else already made the JTW signature decryption so it's safe to asume that any information in it is legit
7. If carsMicroservice needs some user specific information, for example this being a post for creating a new car, for some reason instead of using the subject field from the JWT token that's the uuid of the user, we want a user name -> car association so when the request reaches carsMicroservice, it will DECODE the payload, get the user uid, asks userMicroservice to return all the information about the user with that uid. This communication doesn't need to be secure because it's done internally after all the necessary security checks.

Of course you can enforce this that the only user information a user can access it's his own etc, but these are custom heuristic.