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.
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.