Channel Gateway

The Channel Gateway represents the entry point for a customer facing brands. Examples include the CommBank, NetBank, CommBiz, x15, etc.

A Channel is made up of multiple applications that are composed and published to the customers of a Channel via the Channel Gateway and an application may be published to multiple gateways. The inclusion of an application in a channel gateway is an agreement between the application team and the channel team.

A Channel Gateway is responsible for:

• Presenting customers with a means to access the application:
  • Typically a link or a button on their website (or application)
  • Routing requests received by the channel gateway to the appropriate application
• Authenticating customers and coarse level authorisation before routing requests to the application
• Defining clear expectations for the application team to ensure the application is compatible with the channel including things like:
  • Branding and user experience (e.g. navigation, accessibility, fonts, colours, logos, etc.)
  • Security and Operations (SLAs/SLOs, monitoring, alerting, outages and downtime, etc.)

Applications are responsible for:

• Providing functionality to the channel's customers
• Adhering to the expectations as defined by the channel gateway
• Platform hosting and operations

Implementation

The Channel Gateway is effectively a reverse proxy with additional functionality like:

• Authentication (OpenIdConnect) and authorisation
• Observability (OpenTelemetry)
• Smart routing (e.g. A/B testing, canary deployments and releases)

Current implementation

In this example, the Channel Gateway is implemented in dotnet using the Yarp (Yet Another Reverse Proxy) library with custom configuration and middleware.

The local development environment makes use of docker and docker-compose with the following setup:

services:
  gateway:
    image: ghcr.io/x15ventures/reverse-proxy:latest
    restart: unless-stopped
    ports:
      - '8080:8080'
    environment:
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4318/v1/traces

  # ...

It integrates with a local OpenTelemetry collector provided by dotnet aspire.

The gateway is configured with a routes.yml file that defines the routing rules. Example:

routes:
  root:
    rules:
      path: /
    target: /docs
    auth: disabled
    mode: redirect

  web:
    rules:
      path: /web/{**local-path}
    target: http://web:3000/web/{**local-path}
    auth: required

  docs:
    rules:
      path: /docs/{**local-path}
    target: http://docs:3001/docs/{**local-path}
    auth: optional

In this example, the web application is configured to require an authenticated user with auth: required. When an unauthenticated request is received for the /web path, the gateway will invoke the configured OpenIdConnect identity provider to authenticate the request. Example appsettings.json configuration:

{
  "OpenIdConnect": {
    "Issuer": "https://x15.au.auth0.com",
    "ClientId": "<client_id>",
    "ClientSecret": "<client_secret>",
    "CallbackPath": "/signin-oidc",
    "Scope": "openid email profile",
    "CookieName": "_gw_",
    "PostLogoutRedirectUri": "https://x15.au.auth0.com/v2/logout?client_id=<client_id>"
  }
}

This example uses Auth0 as the identity provider, but any OpenIdConnect provider can be used in its place.

The authentication is between the gateway and identity provider, the application is made aware of the user's identity via the channel gateway. In this example, the channel gateway removes authentication related cookies and produces an new bearer token that is presented to the application.