Access Gateway has a number of architectural components and tiers.
The following diagram shows a detailed hypothetical architecture overview of Access Gateway, along with ports and protocols used.
The topmost tier contains the traditional internet access, typically exposed using a load balancer. Users access the load balancer using application specific URLs. These URLs then direct them to an Access Gateway worker node in a high availability cluster.
The middle tier contains the Access Gateway cluster, running within a virtual environment, such as Amazon EC2, Microsoft Azure, VMWare, and others.
An Access Gateway cluster is composed of:
The following is the minimum recommended configuration for a high availability Access Gateway cluster.
- A load balancer that is visible to the external internet and the Access Gateway cluster.
- An admin node that manages all application definitions and supports infrastructure, such as data stores and other configuration.
- Three or more worker nodes that manage all application requests, interact with an Okta tenant for authorization, provide fine-grained access controls, and other behaviors. 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:
- www.okta.com - Used for initial configuration and network testing.
- yum.oag.okta.com - Used for upgrading Access Gateway.
- vpn.oag.okta.com - Used for support and troubleshooting.
- Other ports as required for DNS, Kerberos, and Syslog access.
Administrators need to be able to access the Access Gateway 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. Care should be taken not to open port 22 outside the firewall.
When initially configuring a high availability cluster, cluster members communicate using HTTPS over port 443. Caution should be exercised when configuring high availability where proxies are in use. See Proxy configuration in the Network section of Command Line Management Console reference for information on configuring proxies and proxy bypass lists.
Protected web applications, typically running within a client data center, represent the lowest tier in the architecture. These applications must be accessible to Access Gateway, but should not 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. Additionally, a firewall typically separates Access Gateway from the application tier load balancer.
Access Gateway supports the use of additional network interfaces, which can be used to separate differing aspects of data center to Access Gateway traffic.
Prerequisites for deploying Access Gateway