Protected application reference architectures

When integrating applications with Access Gateway there are a number of ways to ensure that back end resources are not only protected but also inaccessible from the normal external internet. The following architectures describe different methods that can be used to ensured that protected web resources are not accessible from the internet.

Approach

When integrating applications into Access Gateway the following should be considered:

  • DNS - how will DNS be served to Access Gateway?
  • How will firewalls be implemented.
  • Are their specific IP address restrictions?
  • Are there any other integration specific requirements.

Protected application architectures

Access Gateway application integrations installations can be deployed in any number of possible combinations. In all architectures the URL used to access the application is the same. That is both internal network and external network accesses rely on the same application name (app.example.com).

Common application integration protection architectures include:

Not protected Initial starting point for all protected web application architectures. By definition provides little or no protection for external access to protected web resource.
Masked DNS An expansion of the None architecture which adds a secondary internal DNS server, used by Access Gateway, which resolves the name of the protected web resource but is different than the external applications URL.
Firewall An expansion of the Split DNS architecture which places firewalls in strategic places denying routing of requests for IP addresses on the internal use internet.
Protected IP An expansion of the Firewall architecture, Protected (or restricted) IP, adds IP address based restrictions allowing or denying access to resources based on requester IP address.
Certificate challenge An expansion of either the Firewall or Protected IP address architectures, the certificate challenge architecture installs custom certificates used to allow or deny access to protected web resources based on whether the requester can successfully reply to a certificate challenge.

Architecture functional area breakdown

Architectures are broken down into the following functional areas:

External internet The external internet represents clients that access applications, as well as including your Okta Org.
DMZ The DMZ houses an Access Gateway cluster, and associated components, to allow access to applications from the external internet.
Internal The internal network houses the applications being protected by Access Gateway as well as other components required to make these applications widely available.

Note that in all architecture diagrams, dotted lines represent paths around Access Gateway, which are meant to be denied. Each architecture details the process used to deny these paths.