How to Deploy a BeyondCorp-Style Web App Behind the ScaleFT Access Fabric

December 13, 2017

by Ivan Dwyer

The following is a step-by-step walkthrough of how to deploy your own applications in a similar manner as Google’s BeyondCorp using ScaleFT Web Access. We recently announced general availability of the ScaleFT Access Fabric, the globally distributed, real-time auth system backing our platform.

Introduction to BeyondCorp

In the wake of a 2009 nation-state attack, Google began an internal initiative to redesign their corporate security architecture with regards to how employees and contractors access internal company resources. They recognized that the traditional network perimeter-based security measures were breaking down with the rise of the cloud, SaaS applications, and more remote workers. The result of the initiative was a Zero Trust architecture shifting the access controls to Layer 7, enabling Google employees to work securely from any location without the use of a VPN. Better security without impacting productivity – the best of both worlds.

For a more in-depth look at BeyondCorp, you can read the research papers put out by Google explaining the architecture at:

At a high level, BeyondCorp is built on 3 core principles:

  • Connecting from a particular network must not determine which services you can access
  • Access to services is granted based on what we know about you and your device
  • All access to services must be authenticated, authorized, and encrypted

BeyondCorp itself may be specific to Google, however, we can all look to their implementation as a guide to accomplish a similar outcome. It’s our mission at ScaleFT to make BeyondCorp achievable by companies of all kinds without having to build it yourself.

Since the pre-release of the Access Fabric in July, we’ve worked closely with a number of companies to perform proof-of-concepts, and have learned a lot about what people really want out of a modern Zero Trust security platform. With the Access Fabric, the backing access controls are now in place to support dynamic web application authentication and authorization, but we know that we have a ways to go before the full realization of a BeyondCorp-like system, and are continuing to work on things like access policies, mobile device support, and MDM integrations.

What’s an Access Fabric?

If that term is new to you, that’s perfectly natural – we recently introduced it as the name for the data plane backing our platform. In the context of BeyondCorp, this includes the Access Proxy and Access Control Engine. As evidenced by Google’s own implementation, in order to effectively stop trusting the network, you need to have Layer 7 access controls instead, which can authenticate and authorize requests based on ever-changing user and device conditions. To accomplish such a feat without damaging the end user experience, you need a globally distributed real-time processing system capable of making intelligent decisions at the edge. At ScaleFT, that’s our Access Fabric.

The Web Access Workflow

To the end user, the workflow is as simple as it gets – just visit the hostname as if it were a public website. For this example, I made something basic – a lunch menu: (Really, though… every day should be Acai day)

Now there’s nothing particularly interesting about visiting a website, but remember that in a BeyondCorp world, this is an internal application deployed on a public network – the Internet. As such, there are a number of actions happening behind the scenes that make visiting this app follow the Zero Trust principles of BeyondCorp:

  • The client communicates with the Access Fabric over HTTPS. The Access Fabric terminates TLS and checks for the presence of two cookies: a session cookie which attests to a valid authentication with your Identity Provider, and an authorization cookie which attests to a request authorized by ScaleFT according to the RBAC and policies associated with the Project. Only once both are present is traffic forwarded to the origin. If one or both do not exist, the respective auth workflow is initiated.

  • ScaleFT is integrated with your company’s Identity Provider of choice for the authentication process. This could be Okta, G Suite, or Active Directory to name a few. The request is then authorized against the RBAC configurations and Access Policies associated with the project the application is in. In ScaleFT, policies can take into account dynamic conditions such as user attributes, device state, and session data, all of which are continually funneled through a Kafka-backed pipeline to the Authorization Engine. We make a best effort to reflect configuration changes in near real-time, so if a policy is updated, or a user is removed from the IdP, or the user turns off device security features, the system will know close to instantly and react accordingly.

  • In order to perform the auth processes in the Access Fabric, we terminate the TLS connection at the proxy service. Once the auth workflows are complete, a new TLS connection is initiated between the Access Fabric and the origin. Within this connection is an unsigned header representing the user and a signed header representing the session. The signed header is JWT with a TTL of 30 seconds (to account for clock drift), and the signature must be validated to ensure the connection originated from the Access Fabric. This can be done through a proxy such as Apache or Envoy, or by handling the JWT yourself. Read our documentation on this topic for a deeper dive.

Deploying a Web App Behind the Access Fabric

Now that we’ve seen the behind-the-scenes workflow, let’s cover the process of configuring an application for ScaleFT Web Access. With the Access Fabric providing dynamic access controls as a service by ScaleFT, all you need to do is allow ingress to your HTTPS application from the Access Fabric. Once a request has been authenticated and authorized, the connection from the client is proxied through the Access Fabric to the resource. Signed credentials in the form of JSON Web Tokens are added as well-known HTTP headers for your application to validate.

Note: Signed headers are currently the only way to validate that a request comes from the Access Fabric, so validating these is critical to securing any application deployed behind the Access Fabric. Read the Docs

Create a ScaleFT Project

In the ScaleFT Platform, a project is the logical grouping of users, groups, and resources. For example, you can have a dev and prod project respectively, with RBAC and access policies governing permissions for each. From the ScaleFT Dashboard, select ‘Projects’ from the menu, and then the ‘New Project’ button. Enter in the Name of your project. For this example, we’ll just call it ‘ivan-test-a’. The configuration items here are meant for our Server Access product, so you can ignore for now.

Configure an Access Fabric Application

To make this an Access Fabric application, we enter the hostname and the origin. One caveat here is that I’m running a web server on AWS, and using Let’s Encrypt to create my SSL certificates. This means I need to create a CNAME record for the EC2 instance because Let’s Encrypt blacklists domains due to their volume and ephemeral nature.

I’m using Route 53 to manage the domain, so I’ll create a CNAME Record Set for to point to the EC2 instance. This site is named under the “backend” subdomain because this will point to the service which the Access Fabric connects to.

I will then use as the origin and as the custom user-facing hostname to create the Access Fabric application. On the EC2 instance, I use Certbot to create an SSL certificate for

ScaleFT will create the Access Fabric application and assign it an Application URL – we refer to these internally as “cute names” because they are generated as a combination of an adjective, a mythical creature, and a random 4-digit number. This example gave me ‘’. ScaleFT has a wildcard certificate for all subdomains of

I’ll create another CNAME record set in Route 53 for my custom hostname to resolve to the Access Fabric Application URL.

Validate the Signed Header

As mentioned, validating the signed header is important to ensure the only traffic reaching the origin comes from the Access Fabric. There are a number of ways to perform this validation as covered in our Docs, and we’ll be releasing more tools and examples to help make it easier.

We’re also hard at work to support alternative deployment configurations in the future, including private networks and mutual TLS authentication. For this example, let’s install and configure an Apache module our team recently open sourced to perform the verification. You can find the module with installation instructions here:

First, we need to install few dependencies.

$ sudo apt-get install -y build-essential curl libcurl4-openssl-dev libssl1.0.0 libssl-dev openssl libjansson-dev apache2-dev

We also open sourced a JWT parsing library called libxjwt, which we need to install.

$ wget $ tar -xvzf v1.0.2.tar.gz $ cd libxjwt-1.0.2 $ ./configure && make $ sudo make install

Now we can install and configure mod_auth_accessfabric.

$ wget $ tar -xvzf mod_auth_accessfabric-1.0.1.tar.gz $ cd mod_auth_accessfabric-1.0.1 $ ./configure && make $ sudo make install

The last step is to load the apache module in the configuration, and set the AuthType to the Access Fabric. Add the following lines to your apache configuration file. Set the audience as the fqdn of your Application URL aka the “cute name”.

LoadModule auth_accessfabric_module /usr/lib/apache2/modules/ <Location "/"> AuthType AccessFabric AuthAccessFabricAudience "" Require valid-user </Location>

It’s also good practice to add a custom log format for Access Fabric requests. Add the following lines to your apache configuration.

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" %{auth_accessfabric_sub}n \"%{auth_accessfabric_email}n\"" extended-af CustomLog "/var/log/apache2/af_access_log" extended-af

Restart apache so the configuration changes are reflected, and visit the web app. Requests will be logged by the Access Fabric as follows. - [13/Dec/2017:18:45:18 +0000] "GET / HTTP/1.1" 200 1430 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36" 718ee615-7e51-49e1-84d1-c065e3f74b3e ""

Let’s also inspect the signed header, to validate the contents of the JWT. I added a simple phpinfo(); page that outputs the contents of the AUTHENTICATED-USER-JWT header. I’ll use a handy tool from the folks at Auth0 to peek into the JWT.

With this configuration in place, you can be confident that all traffic to your protected resource has been fully authenticated, authorized, and encrypted – one of the core principles of BeyondCorp.

Attaching Policies to a Project

Role based access controls are a great way to specify who can access which applications, but in a BeyondCorp-style implementation, we want to take it even further and factor device state into the authorization process. A lunch menu isn’t a very sensitive application, but what about your corporate wiki that contains a wealth of privileged information? In that case, you’ll want to make sure the connecting users have secure devices.

Keeping up with software updates and proper device hygiene across an entire company is a common pain point IT and Security departments constantly struggle with. The security industry puts a lot of emphasis on education and compliance, but that places too much individual responsibility on the users. You can write policies all day long, but adhering to them is a real challenge. How is it that Google was successful in this regard over others? They did so through an engineered solution that effectively automated the encouragement of good choices. When you are denied access to a resource you need to do your job because of a missing software update, you’ll go install that software update. When remediation is built into the workflows, users are more encouraged to stay up-to-date, which is more effective than a written policy.

ScaleFT Web Access follows a similar approach with its Access Policies (this feature is currently in early access). A policy is a collection of conditions which must all be true for a user to access a resource from a device. Ex: “Is the disk encrypted?” or “Is the OS up-to-date?”

For this example, I have a Wiki app I want to place behind the Access Fabric. I follow the same steps as I did with the Lunch Menu app in a new Project, and then select the ‘Permissions’ tab. Because it’s a Wiki app, I want to make sure the connecting device has disk encryption turned on, because users can download various resources directly to their local drives. I’ll select the ‘disk_encryption’ policy that is available to my Team.

This policy is now a part of the authorization process for any resources within the Project. If I turn off disk encryption on my laptop, and then try to visit, the request is denied. I am presented a helper message that explains why, and what I need to do to self-remediate. As with BeyondCorp, it’s our belief that encouraging remediation is a more effective way to ensure users naturally maintain proper security posture.

Getting Started With ScaleFT

When looking at BeyondCorp purely through the lens of Google, it may appear out of reach, but with ScaleFT Web Access, you can achieve the same outcomes for your internal web applications in just a few easy steps. To get started yourself, sign up for a free 30-day trial or get in touch with us directly to learn more.

BeyondCorp Zero Trust Access Fabric Web Access

Ivan Dwyer

Ivan Dwyer is the VP of Product Marketing at ScaleFT, working with the community to raise awareness around BeyondCorp and Zero Trust for organizations of all kinds looking to modernize their security architecture.

Subscribe to the ScaleFT Newsletter to get the latest and greatest delivered straight to your inbox.

Sick of VPNs?

All of our plans start with a 30 day free trial. No credit card required. See our flexible Pricing Plans.

Start a Free Trial Request a Demo