Deploying to the Access Fabric


In order to put an application behind the Access Fabric you will need to:

  1. Create an Origin URL that the Access Fabric will use to access your application
  2. Create an Access Fabric application in ScaleFT, which will generate an unique URL for your application
  3. Configure the Origin server to validate and serve traffic from the Access Fabric
  4. Typically, create a CNAME from the URL at which you want users to access the application to the unique URL which ScaleFT generated

Choosing an Origin URL

An Origin is a URL to which ScaleFT will forward traffic after it has been authenticated and authorized by the Access Fabric. This must be different than the URL at which users visit your application. For example, to secure access to https://wiki.example.com you might choose to use https://wiki-origin.example.com as the origin URL.

Creating an Application

Access Fabric applications belong to Projects in ScaleFT and inherit any permissions applied to that project. To create an application log in to ScaleFT as an administrator, browse to the project in which you wish to create the application, click the Applications tab then click “Create Application”.

Fill in:

  1. The Origin URL you chose above
  2. A custom URL at which you wish for users to eventually access the application

Then click Submit.

Upon creation your application will be assigned a unique Application URL such as https://practical-wyvern-2101.accessfabric.com.

Configuring the Origin Server

There are three important configuration changes which are typically needed on an Origin server in order for it to successfully and securely serve traffic from the Access Fabric.

TLS Configuration

When the Access Fabric connects to the Origin it will negotiate a TLS connection before sending any requests. During this process the Origin server must be able to present a certificate for the Origin URL. For example, if the Origin URL is https://wiki-origin.example.org, the Origin server must present a CA-signed certificate for wiki-origin.example.org.

Host Header Matching

When the Access Fabric passes a request to the Origin the Host header set on the request will reflect the URL that the user visited to view the page, not the host name in the Origin URL. This enables applications which utilize Host headers, for example when generating URLs, to continue to function unmodified behind the Access Fabric.

If the Origin web server is configured to perform Host matching (for example using server_name directives in nginx, or VirtualHost blocks in httpd) you will need to add an entry corresponding to any URL you expect users to access the application at, including the *.accessfabric.com Application URL and any custom hostnames you intend to configure.

Note: it is possible to serve multiple Access Fabric applications from a single Origin URL by configuring a proxy at that URL to route traffic based on Host headers to the correct application. This can be used in advanced deployments to build a centralized cluster of Origin proxies, and makes it very easy to bring additional applications online.

Validating Access Fabric Traffic

Before going live with an Access Fabric application, the server at the origin URL must also check for signed attestations from the Access Fabric - otherwise anyone who discovers the Origin URL can simply access it directly.

Testing the Application

When deploying an application that is already in use by users, in order to avoid a service interruption you will wish to test that the application functions as expected behind the Access Fabric before re-routing end user traffic. There are two ways to accomplish this.

For new applications skip to Redirecting End User Traffic.

Testing Using the Access Fabric Application URL

The easiest way to test most applications is to simply visit the *.accessfabric.com URL assigned when you created the Access Fabric application.

This requires that the origin application function correctly when accessed at this URL, including having Host header matching configured correctly as described above. Some applications have URLs hard-coded or configured in a way that you don’t wish to change; for those applications, see below.

Testing Using a Modified Hosts File

Applications can also be tested by modifying your hosts file (/etc/hosts on macOS and C:\Windows\System32\Drivers\etc\hosts on Windows) to send application traffic through the Access Fabric instead of directly to the original location.

For example, if your application is usually accessed at wiki.example.com, you would create a local rule pointing that name to the Access Fabric.

To do so, first look up the IP address that your application’s Access Fabric URL points to, for example by running dig practical-wyvern-2101.accessfabric.com.

Then modify your local hosts file, adding a line such as:

35.227.203.174   wiki.example.com

Now, when you visit https://wiki.example.com your traffic will be routed through the Access Fabric.

Note: while this approach is suitable for a short term test, the IP associated with an Access Fabric URL can change over time, so it shouldn’t be used directly in production-ready configurations.

Redirecting User Traffic

To redirect traffic to your application through the Access Fabric, create a CNAME DNS record pointing from the address at which user’s access your application (eg, wiki.example.com) to your Access Fabric Application URL (eg, practical-wyvern-2101.accessfabric.com).

This step requires that your application have a Custom Hostname configured to match the CNAME record.