OpenZiti BrowZer Gateway

Architecture Overview

OpenZiti BrowZer Gateway

Introduction

I recently introduced you to BrowZer, a new group of open source components from the OpenZiti project that enables automatic embedding of zero trust networking into web applications (← the earlier intro article ↑ will help put this article into broader context)

Meanwhile, the TL;DR is that BrowZer's goal is to prevent your internet-facing web applications from being attacked by malicious threat actors.

This article is part of the ongoing web application security series concerning BrowZer, and here I will provide an architectural overview of its gateway component — or what we internally refer to as the HTTP Agent.

The BrowZer Gateway (HTTP Agent)

The BrowZer architecture involves a gateway which facilitates bootstrapping of trusted network sessions between your authorized users and your web app.

Unlike traditional approaches (like VPNs) where all network traffic, from all remote users, funnels into and is concentrated within a single gateway..., BrowZer takes a very different and novel approach.

The BrowZer component that acts as the gateway is the HTTP Agent.

The "big picture" diagram shown on the left side below was first seen in the introductory BrowZer article. Here in this diagram I added an annotation showing where we will zoom in and focus in this article. The remaining BrowZer components will be discussed in upcoming articles in the series.

image.png

In the sections that follow, I will briefly describe the responsibilities of the BrowZer Gateway and the sequence of steps it uses to bootstrap your users onto the trusted network.

An upcoming related article will explain how to deploy the BrowZer Gateway.

Bootstrapping Trusted Network Sessions

In a BrowZer environment, your web app will be dark — with no open incoming ports to the internet. It is invisible to threat actors, and thus unassailable.

Your authorized users will still have access, and will do so via an OpenZiti overlay network. The process of getting onto that overlay network begins with the BrowZer Gateway.

The various operations carried out by the BrowZer Gateway are discussed in sub-sections below, and they include:

  • Residing at a well-known DNS name

  • Integrating with an IdP

  • Responding to incoming HTTP requests

  • Causing the ZBR to be loaded into the browser

DNS Name

Traditionally, your internet-facing web app would be hosted at some DNS name that you own. For discussion purposes here, let's generically refer to this DNS name as webapp.doma.in. When a user wants to access your web app they would enter https://webapp.doma.in into their browser's address bar, and then your web server would begin responding to HTTP requests from the browser.

Now, let's transition to how things work in a BrowZer environment.

The web app will be transitioned out of public view, made invisible to the internet, and the BrowZer Gateway is then deployed such that it is the web server that will respond to browsers that visit https://webapp.doma.in.

(Of course, if you wanted to create a new/different DNS name for the BrowZer Gateway, you could certainly do that, then socialize the new name with your users, and retire the original name.)

SSO with Identity Provider (IdP)

The first step a user will take to gain access to the OpenZiti network in a BrowZer environment is performing a single sign-on (SSO) that provides a strong assertion of the user's identity.

This SSO requirement means that BrowZer needs an IdP to be associated with the OpenZiti overlay network. Which IdP is used, and whether it federates out to yet another provider, is up to you. It could be ADFS, AzureAD, Okta, Auth0, etc. Each of these IdP's could in turn federate out to Google, GitHub, Twitter, Facebook, etc.

This diagram shows a conceptual example (which happens to resemble what we use internally at my company for one of our own dark web apps):

image.png

When an HTTP request is received by the BrowZer Gateway listening at your https://webapp.doma.in address, it will examine the HTTP request to determine if the SSO has previously been done, or not.

If the BrowZer Gateway determines that the SSO has previously been accomplished (i.e. a browserSession cookie is present on the HTTP request), it will continue processing the HTTP request as described in the next sub-section.

If the BrowZer Gateway determines that the SSO has not been accomplished, it will use OIDC protocol to instruct the configured IdP to prompt the user for their credentials. The IdP will not return control to the BrowZer Gateway until the user has successfully authenticated.

Upon successful return from the IdP/SSO flow, the BrowZer Gateway will extract the necessary OIDC information returned from the IdP, and establish a browserSession cookie for the user. It will then continue processing the HTTP request as described in the next sub-section

Responding to HTTP requests

It is import to keep in mind that the BrowZer Gateway's role is NOT to act as a reverse-proxy to the dark web app. In fact, the BrowZer Gateway will never send/receive HTTP requests to/from the dark web app.

Beyond facilitating IdP credential validation, the BrowZer Gateway's only task is to get the Ziti BrowZer Runtime (ZBR) loaded into the user's browser, and then it simply gets out of the way!

Above we alluded to how the BrowZer architecture is novel and game-changing (when compared to traditional VPN approaches).

This game-changing reality manifests as a result of the following flow:

  1. dynamically loading the ZBR into the user's browser

  2. dynamically loading configuration info such as control plane coordinates, which Identity wishes to authenticate with the network, and the OpenZiti Service-name associated with the dark web app

  3. the now-client-side-resident ZBR interacting with the OpenZiti control plane to perform network authentication (before being allowed to connect to the OpenZiti network)

  4. the fully-authenticated and client-side-resident ZBR doing all the work necessary to load the web app into the browser, over the OpenZiti overlay network, from the dark web server

  5. the client-side resident ZBR then ensuring that all subsequent HTTP requests made by the client-side-resident web app are also routed over the OpenZiti overlay network if the requests are targeting the dark web server

Summed up:

Workload is now globally-distributed since the clients (ubiquitous browsers) themselves will do the work necessary to login to the OpenZiti mesh network and load the dark web app over that OpenZiti mesh network.

No central VPN-concentrator ─ No tedious error-prone IP-white-listing ─ No painful VPN credentials management ─ No reverse-proxy ─ No additional client-side VPN software to install and run ─ No modifications to your web app.

image.png

NOTE: Upcoming additional articles will be published in this series, and they will do deep technical dives into the Ziti BrowZer Runtime (ZBR) internals, as well as how the IdP-provided Identities are integrated into the OpenZiti control plane, so be sure to subscribe to this blog to receive further educational materials.

BrowZer Gateway Deployment & Configuration

Customers of our CloudZiti offering will have everything described in this article automatically orchestrated for them.

Meanwhile, if you are a user of our OpenZiti open source offerings, and you'd like to take BrowZer out for a spin, then you will be interested in reading the next article in this series where I describe how to configure and deploy your own instance of the BrowZer Gateway. It should be published in the next few days.

Wrap up

Do you host a web app and want to be invisible to malicious intruders?

Do you want your users to have easy access from anywhere with no additional software on their client device?

Do you want to do all this without making any modifications to your web app?

If you are nodding yes, then we hope you'll join our community and try BrowZer.

Please subscribe to this blog to be notified of more information concerning how to succeed.