Microservices and API Gateways

by Sascha Preibisch

Environments that serve microservices are very complex. Users and applications have to be authenticated and authorized, APIs have to verify granted permissions, and revocation has to be supported often. Microservices may be deployed in a closed network but may be in a distributed cloud environment. If all aspects of a service are left to their developers, these developers will hardly ever get everything done, and they won't be able to adhere to best practices for whatever they are working on. Micro gateways can help here!

Since I am a big fan of API Gateways, I certainly see a role for them in microservices environments, too (but, to be honest, a slightly modified version of them: an API gateway that is sometimes referred to as "micro gateway" or "edge gateway.") As it turns out, I am not the only fan of such products. If you search for those terms you will find products made by IBM, wso2, apigee, Broadcom, CA Technologies, and others. What they have in common is the idea of a lightweight gateway that protects single back end APIs, or maybe a group of them, if they form a feature when working together. They are also not deployed on their own.

Figure 1 displays a setup similar to one that I have presented at CA World 2017 in Las Vegas. The setup contains two different types of gateways: an Ingress gateway, which receives requests from the "outside" world, and a Microgateway, managing connections to and from microservice implementations in the "internal."

New Content Item

Fig. 1: Example setup featuring a Microgetaway

The main job of the Microgateway is the protection of microservices. No invalid request should reach the Microgateway. In particular, the Microgateway can take care of these tasks:

  • Validate incoming JWT that were issued by the Ingress gateway
  • Apply rate limits to protect the microservice from being overloaded
  • Issue JWT for specific use cases, signed by their own private key
  • Implement its own JWKS endpoint so that any entity can validate its JWT
  • Transform messages from and into formats that microservices expect

Compared to an Ingress gateway it requires less resources. An Ingress gateway will handle the traffic of many more messages, it may be a fully-fledged OAuth/OpenID Connect server, it will handle user and client authentication, it will issue JWT-based credential when forwarding requests to a Microgateway, it will maintain a database with long and short-lived token.

The Microgateway on the other hand, due to its very focused tasks, may run as an ephemeral container which allows easy scaling and replacement of it. For additional security, having an automated registration and validation process it is possible to have them receive TLS/SSL certificates that are signed by an internal Certificate Authority (CA).

Having an internal CA (see Figure 1) leads to an environment in which microservices and Microgateways only trust connections that use such certificates, signed by that CA. This has a very big advantage: if, in a worst-case scenario, an intruder makes it into the network, it will still not be able to consume any APIs (neither microservices nor Microgateways.) An intruder will not possess a certificate signed by that CA.

To summarize the described setup, here are the highlights:

  • An internal CA can help secure Microgateways and microservices at the TLS/SSL level
  • JWT, issued by Microgateways, secure systems on message level
  • Ingress gateways that forward session details enable Microgateways to do the “heavy lifting” in regard to validations and message transformations

About the Author

Sascha Preibisch has been involved in enterprise-grade software development since 2005. He worked as a consultant in Switzerland where he helped customers expose SOAP-based web services in a secure way. Today, as software architect for CA Technologies in Vancouver, Canada, he works with customers who expose RESTful services. He advises customers in the usage of OAuth, OpenID Connect, mobile API security, and SSO between mobile and desktop applications. Sascha regularly attends the Internet Identity Workshop (IIW) in Mountain View,California, USA, which is the birth place of OAuth 2.0 and OpenID Connect. He is a member of the OpenID Foundation. He maintains a blog on all aspects of API development, and he wrote a short book about a software framework (Application Development with XML, Eclipse RCP, and Web Services). Sascha holds a patent on a secure mobile app registration protocol. 

This article was contributed by Sascha Preibisch, author of API Development.