API Gateways provide a set of features that enable secure access to its API endpoints. These features fall under three broad categories:
An administrator of any API Gateway platform need to be aware of these capabilities, which could be a bit different compared to securing web sites and databases.
There are a few important considerations beyond what most administrators typically manage.
How can you define microservices and serverless functions and expose them as APIs? What about industry best practices for API Management?
Defining microservices and serverless functions and exposing them as APIs is just the beginning and can take time to do it right. For developers, industry standard authentication, authorization and audit capabilities also come at a price: time, scale and resources. It takes an experienced dev to ensure that these practices are followed throughout the entire software development lifecycle.
Express Serverless Platform is a Microservices and Serverless Platform for APIs. It is unique in that it allows us to design and deploy microservices.
The platform allows us to expose both model-based microservices and serverless Functions through REST APIs, using an API Gateway (the open source Express Gateway).
The Express Serverless Platform is unique in that it brings together tooling to develop microservices, and one-click deployment to a scalable Kubernetes infrastructure. This accelerates development and significantly increases developer productivity. The tooling environment is actually browser-based and known as Canvas.
Let’s focus some attention on the API Management component, that is, Express Gateway. However, all configurations on Express Gateway, including those relevant for authentication, authorization and audit, can be applied through the Canvas.
Express Gateway supports three industry standard mechanisms for client authentication: basic authentication (username / password), Key-based authentication (using API access Keys) and OAuth2 (for granting access to APIs from third-party applications).
Authorization mechanism in Express Gateway is simple and innovative. For each API endpoint, the administrator can specify one or more scope(s). A scope is just like a tag indicating the type of users / applications that may need access to this API endpoint. Correspondingly, users granted access to the API gateway may be assigned one or more scopes. A user can retrieve information from an API only if she is assigned a matching scope.
This is a fine-grained authorization mechanism because:
Audit capabilities in Express Gateway are based upon customizable logging options. The administrator can include a customizable log message for each pipeline, that will apply to each incoming request on that pipeline. By including important request parameters like IP address, user id, request URL, etc., each request can be analyzed for malicious activities.
|basic-auth / key-auth / oauth policy||scopes||log policy|
Express Gateway allows us to create API endpoints and then control how client requests for any given endpoint is handled. This is achieved by defining a pipeline for each endpoint and placing a set of ‘policies’ in a specific order in the pipeline. Express Gateway is built on top of the Node.js Express framework, and the policies are akin to Express.js middleware. Authentication is set up by adding one of the three policies: ‘basic-auth’, ‘key-auth’ or ‘oauth’ to a pipeline. Audit logs can be enabled by adding the ‘log’ policy. Authorization (scopes) is an attribute of an API endpoint and is not implemented as a policy.
First, we will work with a simple API endpoint that simply supplies the Coordinated Universal Time (UTC) now.
To implement this API endpoint, we will make use of the existing URL: http://worldclockapi.com/api/json/utc/now , instead of reinventing the wheel. When we access this URL, we receive a response body containing the UTC time in JSON format:
Therefore, our job would be to create an API endpoint on the Express Serverless Platform, that wraps around the above URL. This API endpoint will respond with the current Universal Time. Furthermore, we will enforce authentication, authorization and audit on this API endpoint by applying suitable configuration settings.
In a more realistic scenario, an organization using Express Serverless Platform would build a service on its own that it wants to expose externally as an API. But our goal is to focus on the traffic management feature. So we will try not to code a new service from scratch. Stay tuned, because in our next post we’ll dive head-first into technical detail on how to get this done.
If you’re interested in more of these topics, join the live discussion on twitter (@lunchbadger) or (@express_gateway).