Components

Access Gateway has several architectural components and tiers. The following diagram shows a detailed hypothetical architecture overview of Access Gateway, along with ports and protocols used.

Top tier

The topmost tier contains the traditional internet access, typically exposed through a load balancer. Users access the load balancer by using application-specific URLs. These URLs then direct them to an Access Gateway worker node in a high availability cluster.

Because the worker node acts as a reverse proxy between the user's browser and the protected application, the public-facing load balancer must use sticky sessions.

Middle tier

The middle tier contains the Access Gateway cluster, which runs in a virtual environment, such as Amazon EC2, Microsoft Azure, or VMware.

The worker node cluster runs within a Demilitarized Zone (DMZ). The admin node runs in a separate, more restricted network segment outside the DMZ.

An Access Gateway cluster has the following components:

Note:

The following is the minimum recommended configuration for a high availability Access Gateway cluster.

A load balancer that's visible to the external internet and the Access Gateway cluster.
An admin node, outside the DMZ, which manages all application definitions and supports infrastructure, such as data stores and other configuration.
Three or more worker nodes, inside the DMZ, which manage all application requests, interact with an Okta tenant for authorization, and provide fine-grained access controls. While Access Gateway can function with fewer than three worker nodes, for high availability the recommended minimum cluster size is three (plus an admin node).

The Access Gateway cluster is typically behind a firewall and accessible only to the Okta tenant, load balancer, supporting services, and underlying protected web application resources. In addition, Access Gateway must also be able to access certain well-defined sites such as:

Okta API and Yum repo - Used for initial configuration, network testing, and to upgrade Access Gateway.
A System Log receiver (optional) to forward events to a Security Information and Event Management (SIEM) system. Depending on the SIEM, the worker nodes may send events directly.
Other ports are required for DNS and other services needed by applications.

Administrators must be able to access the command line management console using secure shell (SSH) over port 22 and the admin console using HTTPS over port 443. Typically, these tools are used exclusively by admins inside the firewall. Don't open port 22 outside the firewall.

Note:

When you initially configure a high availability cluster, cluster members communicate using HTTPS over port 443. Use caution when you configure high availability where proxies are in use. See Command Line Management Console reference.

Application tier

Protected web applications, which typically run within a client data center, represent the lowest tier in the architecture. These applications must be accessible to Access Gateway, but shouldn't be accessible to the outside world. Separation of the applications is typically handled using a split DNS mechanism where internal resources, such as protected web applications, databases, and other required support, are visible only to Access Gateway and required data center resources. Also, a firewall typically separates Access Gateway from the application tier load balancer. Access Gateway supports the use of more network interfaces, which can be used to separate different aspects of data center to Access Gateway traffic.