Single Access Gateway server architecture

The single server Access Gateway architecture represent the minimum components required for protecting web resources using Access Gateway. In this simple architecture, a set of applications, referred to as protected web resources, are served to requesting clients using Access Gateway.

This is a minimal architecture typically used for informational purposes.

This architecture is designed to meet the following requirements:
  • Providing secure access to a set of applications, accessed from the external internet, but housed within an internal network.

Benefits and drawbacks

Benefits Drawbacks
  • Simple, minimal installation
  • Baseline for testing, proof of concept etc
  • Provides no support for fault tolerance
  • Not intended for production
  • Administration server access requires SSH port 22, and HTTPS ports 443, be open. See Access Gateway deployment prerequisites for details.

Architecture

Components

Location Component Description
External internet Web clients

Traditional client browser accessing Access Gateway using known as [appN|consumer-app1].example.com URLs.

appN.example.com URL representing one of the applications an external web client would enter to access one of the applications secured by Access Gateway. Typically all URLs of this nature are served by, and resolve to, the Access Gateway instance.
Okta org

Your Okta org, providing identity services.

Firewall External internet to DMZ Traditional firewall between the external internet and the DMZ hosting Access Gateway.
DMZ Access Gateway Access Gateway instance, located in the DMZ is used to provide access to applications used by external internet clients.

Typically hosted in a virtual environment such as Amazon Web Services, MS Azure, Oracle OCI, or similar. See Manage Access Gateway deployment.

Firewall DMZ to internal internet Traditional firewall betweenDMZ and the internal network hosting the protected web resources referenced by Access Gateway
Internal network appN.example.com URL representing one of the applications a web client would enter to access one of the applications secured by Access Gateway. Typically all URLs of this nature are served by, and resolve to, the Access Gateway instance.
Protected applications The set of protected web resources, accessed using the protd-N.internal-example.com URLs. These are the traditional or historic applications which Access Gateway interacts with using the Protected Web Resource field within each application definition.

Possibly fronted by Access Gateway as a load balancer. See Load balancing.

Other considerations

DNS is typically split between external and internal domains. All external URLs, such as [appN|consumer-app1].example.com, would be served externally and point to the Access Gateway instance. Internal URLs, used by Access Gateway such as [protd-N|consumer-app1].internal-example.com, would be served by internal DNS.

Most architectures forward log events to an external syslog component. Okta strongly recommends that a logging server be configured for all Access Gateway environments. See Configure log forwarders.


Additionally, Access Gateway itself is typically managed via internal access only. That is, administrators typically access Access Gateway itself from behind the firewall. This is shown in other architectures.

Related topics

Common Access Gateway flows

DNS use

High availability

About Access Gateway prerequisites