Introducing WSO2 API Microgateway 3.1

WSO2 API Microgateway is a lightweight, developer centric, decentralized, cloud native gateway designed for microservices architecture. As the world is rapidly moving towards microservices, lightweight gateways designed for microservices are becoming more and more popular. This is because microgateways are the key to exposing all microservices as APIs to the outside world and as internal services. What sets microgateways apart is the fact they can be exposed as the client facing ingress gateway to handle North-South traffic and they can be attached as a sidecar to the services to handle the East-West traffic as well.

WSO2 API Microgateway 3.1, the latest version of this product, is enriched with more features to solve your organization’s problems when implementing a microservices architecture.

What’s New?

WSO2 Microgateway 3.1 has a set of features that enables users to explore more areas in a microservices architecture.

gRPC Gateway

gRPC is a client initiated communication mechanism on top of http2, where clients call a service on a remote server as if calling a local method on the client side. It defines the Interface Definition Language (IDL) and the underlying message interchange format using protocol buffers. On the server side, it implements the interface and exposes it as a service; on the client side, it uses a stub that maps the client side method calls to the underlying message format expected by the server. gRPC has become very popular lately and most microservices are implemented as gRPC services. This is to inherit the advantages of http2 protocol which gRPC uses.

With the new release, the microgateway supports exposing gRPC services in a secure manner. gRPC is widely used in service to service communication. This feature is useful when enforcing security on service to service communication which is based on gRPC.

WSO2 Microgateway defines a specific set of proto buf extensions which can be used to enforce the authentication, authorization, and rate limiting for the APIs. Developers can modify the proto buf of the microservice to include additional extensions and include the modified proto buf in the microgateway project which can be later exposed via the microgateway. OAuth2 (opaque and self-contained JWTs), API key, and basic Authentication are the supported security schemes(wso2.security extension) for gRPC APIs. Furthermore, fine-grained authorization can be achieved by specifying the scopes (wso2.scopes extension) for respective gPRC methods in the proto buf. The gRPC method level and service level rate limiting can be specified using wso2.method_throttling_tier and wso2.throttling_tier extensions respectively.

Observability

Observability is a way of measuring the internal state of an application based on the externally accessible outputs. Observability helps to prevent production system failures, notifies users to take the necessary measures beforehand, and allows users to isolate the issues in a live production system. There are three main pillars of observability:

1. Metrics - Aggregatable information
2. Tracing - Request level information
3. Logging - Individual system events

Metrics

Metrics keep track of several important aspects of an application such as latency, resource saturation, traffic, and errors. Metrics help to identify issues that can prevent a production failure and isolate the component of a system that causes issues. In this new release, microgateway by default supports metrics with prometheus and visualizing using grafana. These dashboards help you to identify the latency breakdown of each request, error rates, HTTP status code summary, CPU and memory usages of the gateway, etc.

Tracing

Tracing allows you to track a complete request flow through many different interconnecting components. Once an issue has been identified with metrics, tracing provides insights to isolate the component and of a system that is causing issues. The microgateway registers a set of spans that are defined according to open tracing standards which break down the request flow through the microgateway during different phases such as authentication, authorization, throttling, backend service, responding to the client, etc.

Policy Hub for Message Transformations

Message mediation and transformation are key features of an API gateway. Since these transformations are common to many use cases, what if we can reuse and share transformations among different organizations and developers? The Policy Hub is a centralized location to host custom transformations written in the Ballerina language, enabling reuse by multiple developers.

The microgateway uses Ballerina Central as the policy hub which is a collection of sharable policies. Developers can develop different transformation policies in the Ballerina language and push them to Ballerina Central with meaningful tags. Other developers can search for and reuse the same policies directly for their APIs using the “x-wso2-request-interceptor” or “x-wo2-response-interceptor” extension in their open API definitions. For example, JSON to XML conversion is defined as a very common message transformation scenario. These requirements can be achieved via available interceptors in Ballerina Central.

Java Interceptors for Message Transformation

Earlier versions of WSO2 Microgateway only supported message transformation and mediations using the Ballerina language. The latest release is enabled to support interceptors written in java as well. Developers have the flexibility to implement an interface with a set of helper methods to manipulate a request and response to achieve custom behaviors.

Support for API Key Authentication and Issuing API Keys

Internal APIs and applications accessing restricted APIs may not need stricter security mechanisms like Oauth2. For such APIs, the concept of an API key can be used to provide access to the API. WSO2 Microgateway 3.1 provides out-of-the-box support for API keys. The microgateway also acts as an API key issuer as well by issuing JWT type API keys that can be used to invoke APIs which are protected with API keys. The microgateway’s API security portfolio now consists of full stack OAuth2.0 support, Mutual TLS, Basic Authentication, API Key, and other protocols available as policies.

curl -X get "https://localhost:9095/apikey" -H "Authorization:Basic YWRtaW46YWRtaW4=" -k

External Key Manager Authentication for oAuth2 Tokens

OAuth 2.0 Token Introspection is a specification that defines how a protected resource can validate and obtain meta-information of OAuth2.0 tokens issued by an authorization server. This specification defines an introspect endpoint that provides meta-information including the token validity of a given OAuth2.0 token. The introspection endpoint is implemented on the authorization server-side. The microgateway can connect with any authorization server that complies with Oauth2 standard and implements an “introspection” endpoint, to validate the authenticity of the API request.

Multiple JWT Issuer Support

Certain organizations may use different auth servers for different use cases. Different departments of an organization use different identity providers due to their internal corporate policies. In such scenarios, the gateway must have the ability to work with different auth servers that issue JWTs as auth tokens. WSO2 Microgateway 3.1 can be configured to trust JWTs issued by multiple auth servers.

Apart from the above features, this release contains many improvements like supporting open API definitions without wso2 specific extensions, template the context or base path of APIs, simplified docker image creation during project build and performance improvements.

Explore WSO2 API Microgateway 3.1 For Yourself

WSO2 API Microgateway 3.1 comes with the EULA3 license and you can download it for free. Visit our website to download the latest version. You can also join our Slack channel and speak to API management experts at WSO2.