Light Gateway

With more and more users implementing light-router to bring the legacy clients and light-proxy to bring the legacy services to the light platform, we added many features to both services. Most of the new features are actually from the traditional monolithic gateway products required by our customers. Since we have implemented most of the gateway features and it still has its usage in an enterprise environment, we thought it would be good to create a gateway based on microservices architecture. The new service is called light-gateway, and it is open-sourced in the networknt organization in GitHub.

Like the http-sidecar, the light-gateway combines both light-proxy and light-router features in a standalone service that can be deployed as a Docker container, Windows or Linux service.

Please be aware that all the features listed here are applicable to the http-sidecar.

The following are some ideas to manage the light-gateway.

The following are features we added to the light-gateway:

  • Multiple OAuth 2.0 provider support on the JWT token retrieval and JWT token verification via JWK.
  • Rate Limit helps the gateway regulate the traffic based on server, client, address, and user with optional request paths or services.
  • Path Prefix Service middleware handler supports routeing traffic based on the request paths to different backend APIs.
  • SkipVerifyScopeWithoutSpec flag to avoid scope verification from JWT for backend API endpoints in JwtVerifyHandler.
  • UnifiedSecurityHandler to combine Basic, OAuth and ApiKey together for the same request path.
  • Generic Transformer to transform the request and response before sending to the downstream API or return to the caller.

The following are the products with different configurations.

  • light-gateway to replace the traditional monolithic gateway shared by multiple consumers and providers.
  • light-proxy-client to bring legacy consumers to the light ecosystem with all the cross-cutting concerns
  • light-balancer to enable the high availability of light-proxy-client (LPC) for multiple consumers on the same host.
  • light-proxy-server to bring legacy providers to the light ecosystem with all the cross-cutting concerns.
  • external-access-point to wrap one or more internal or external APIs and expose a single API to the third-party consumers.

Body Sanitization

Introduction In the sanitizer document, we have provided general information about sanitizer.yml configuration and sanitization for the request header and body. All the functionalities are implemented in the SanitizerHandler for services built with light-4j frameworks. However, when the SanitizerHandler is used in the light-gateway or http-sidecar, the body sanitization will be different due to request body interception. The header sanitization is the same, though. Body Sanitizer Plugin When users build a service with one of the light-4j frameworks, the BodyHandler will be used in the request/response chain. Read More »

Header Sanitization

As part of the ecosystem, the light gateway must pass the X-Correlation-Id and X-Traceability-Id to the downstream APIs. To prevent XSS attacks, we normally set up the sanitizer handler on the gateway to encode the above two headers. Of course, you can do the same for other headers based on your business requirements. Handler The first step is to add the SanitizerHandler to the handler registration and the default chain in the values. Read More »

Path Prefix Naming Convention

A better path prefix naming convention can help you manage the gateway more easily when using light-gateway as a centralized shared gateway for many APIs, especially when you have two or more gateways deployed in the DMZ and Corporate network. Path Prefix The path prefix is the beginning of the path in the request URL. In the gateway usage, it can be used to identify the gateway instance, API id and API version. Read More »

External Access Point

The light gateway can be used as a full-blown API gateway, or it can be used as a micro-gateway. One of the use cases is to wrap one or more internal APIs and expose them as a single API to third-party consumer applications on the Internet or Intranet. This is called an external access point. By using the light gateway, we can hide the detailed implementation of the APIs and give third-party consumers a stable and unified API specification. Read More »

Generic Transformer

Overview The generic proxy transformer paired with the Light4J yaml-rule engine, the request/response interceptor handlers allow for request/response body transformation. The supported transformation operations right now are as follows: JSON to SOAP Transformation, SOAP to JSON Transformation, Encoding Transformation and Field Text Formatting. How it Works For all types of transformations that the generic transformer supports, we specify what we need in the rules.yml file. The transformation manager parses the configuration and creates a double-linked list of transformers. Read More »

Unified Security

Introduction This all-in-one security handler combines Basic, OAuth and API Key to be used in a shared light-gateway instance to handle multiple consumers and providers. In a shard gateway use case, we might need to use the following handlers simultaneously in the request/response chain. JwtVerifyHandler ApiKeyHandler BasicAuthHandler This requires the user to position these handlers in the chain carefully so that one handler can skip the verification and pass it to the next handler to do the verification. Read More »

Skip Scope Verification

This is a newly added flag to the openapi-security.yml for the light-gateway to skip the JWT scope verification for the backend APIs that don’t have specifications or specifications that are not deployed to the light-gateway instance. On a centralized gateway, users usually will enable security to ensure all the backend APIs requests are valid. Also, the security handler will protect the admin endpoints injected from the openapi-inject.yml file. Those admin endpoints have admin or {serviceId}/admin scope and need scope verification to be enabled in the openapi-security. Read More »

Path Prefix Service

For the details of the middleware handler, please visit the PathPefixService document. The PathPrefixService handler is one of the middleware handlers that are used to identify the service_id before calling the router handle to route the traffic to multiple downstream APIs. This handler is simple without depending on the OpenAPI specification in the light gateway(LG) and light client proxy(LCP). It is suitable when all the backend APIs have a unique prefix in the request path. Read More »

Multiple OAuth 2.0 Providers

Use Cases There are three deployments that need to support multiple OAuth 2.0 providers: When the light gateway is used as a client gateway or client proxy to bring the legacy client/application to the light ecosystem. The client gateway will be responsible for getting the JWT token on behalf of the native client application. The token needs to be cached and auto-renewed before expiration. Suppose several client applications are deployed on the same host and share the same client gateway deployed on the host. Read More »