Cross-Microservice Authorization and Authentication

Question

Suppose we have a number of (stateless, HTTP-based) (micro)services and a bunch of "daemons", which do all kinds of background processing by actually using said services.

Now, I want to have a way for services and daemons to be able to mutually authenticate and authorize. For example, a daemon that performs full-text indexing of Orders needs:

Read-only access to the Orders, Customers (which itself needs read-only access to Companies service) and Inventory services
Read and write access to the OrdersSearch service in order to be able to update the full-text index.

There are also applications, which operate "on behalf" of the user. For example, Inventory web app needs read and write access to the Inventory service, but the Inventory service itself needs to verify permissions of the user operating the application.

All that said, how do I achieve what I just described? I'd prefer not to use gigantic enterprisey frameworks or standards. From what I've read, Two-Legged OAuth2 is what I need, but I'm not exactly sure.

I was thinkinking of establishing an Authorization service which will be used to answer questions like "Hey, I'm Inventory service. What permissions the Customer service that is calling me right now has for me?", but that has two major weak with distributing shared secrets.

@JoseMartinez Currently, all webapps use standard login-password authentication, no fancy WIFs or SSOs — Anton Gogolev, May 14 '15 at 08:34
See my answer: http://stackoverflow.com/questions/32574103/microservices-how-to-solve-security-and-user-authentication — Akira, Sep 15 '15 at 21:33
Check out a similar Q/A: http://stackoverflow.com/questions/35381163/best-practice-to-organize-authorization-in-microservice-architecture/35401130#35401130 — Bishoy, Feb 16 '16 at 22:28

score 2 · Answer 1 · answered May 14 '15 at 13:22

Authentication:

I imagine an authentication service where a requesting API signs its request using an established protocol: e.g. concatenating parts of the request with a expirable-NONCE and application ID then hashing it to create a signature. This signature is then encrypted with a private key. All requests must contain this encrypted signature and the NONCE as well an application identifier. The receiving service then does a lookup for the requesting application's public-key. After verifying the NONCE has not expired, the receiving service decrypts the digest using the public key and verifies the signature is valid (by repeating the signing process and coming to the same signature). A service would be required for obtaining the public key. A service can cache the application ID to public key mapping.

Authorization:
This can be done using some sort of role based access control scheme. Another service can be used to lookup whether the requesting service has access to the resources being requested.

I think both the authorization and authentication can be done internally, depending on time and money and need for specialization. If you are using Java take a look at Spring Security. If you decide to create custom code please justify it to your managers and get buy in. Do a thorough search online for any other solution and include in your write-up as to why it would not fit and that a custom solution is still required.

Cross-Microservice Authorization and Authentication

1 Answers1