6

I've obviously heard a lot about the Micro-Services Architecture and think it makes a lot of sense (especially with the success stories of Netflix).

I'd like to implement a small Grails application in Micro-Services (although the framework doesn't matter too much). My question is about the "Security" or "Users" Micro Service. My initial thought would be to create an application with a REST interface where my other Micro-Services would query the Security Service's REST interface. However, security would be duplicated in every service. This seems like an inevitable problem, but what is the best way to handle this?

Should I be implementing Spring Security in every service and querying a User Service with simple rights information? Or could a central Security Service work in some way?

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Brandon Wagner
  • 163
  • 4
  • The best way to handle what, specifically? – Robert Harvey Nov 23 '14 at 22:04
  • I'm looking for the best way to setup a central security service without using a specific security framework in all other micro-services. I'm trying to not duplicate as much code as possible. – Brandon Wagner Nov 24 '14 at 01:20
  • I've edited the title of your question accordingly. I've also removed the parts of your question that solicit discussion and ask for offsite resources (neither of which are allowed here), and retracted my close vote. – Robert Harvey Nov 24 '14 at 01:23

2 Answers2

3

as @user454322 says, look up the OAuth2 spec ... it's widely-used and well-supported standard that will work well.

There are (bascially) 2 ways to deploy an authorization server:

1) As a reverse proxy (as shown in @user454322 's diagam). This is when all requests from the outside go through the OAuth2 server and then to your services. This centralizes the authorization concern, so that it's handled before any request reaches the services. This is the same as terminating SSL in the load balancer. In essence, the authorization server becomes a part of your network middleware, like the firewalls and load balancers.

  • the primary downside is that implementing a reverse proxy can be tricky, especially if you have large payloads, or are doing clever things with HTTP (HTTP starts simple, but there are lots of complicated wrinkles it adds)
  • you can buy "API management" solutions which provide the reverse proxy functionality, but add things like OAuth, metrics, throttling, etc.

2) As an authorization server. This is a slightly different layout, where each service takes requests directly (from the load balancers, etc.) Each request comes with an access token in the header. The service then makes an HTTP call to the authorization service to validate the token. The authorization server is responsible for authenticating users and granting tokens in the first place, your micro-services don't have to do that part.

  • the primary downside is that each incoming request has to make a round trip to the auth service. That adds to your latency.
  • a secondary downside is that you have to make sure the every one of your services calls the auth service -- otherwise, any services you don't will be open to the internet and unprotected.
sea-rob
  • 6,841
  • 1
  • 24
  • 47
2

To avoid duplication and improve maintainability, I would go with the central Security Service.

It is said that an image says more than thousand words:

mircoservice architecture security


OAuth is the common way to secure RESTful APIs.
Look at OAuth article on Wikipedia].

user454322
  • 121
  • 3