Comprehensive architecture

The comprehensive architecture is really a super set architecture, representing most of components that might be part ofAccess Gateway. This architecture is designed to meet a number of requirements including:

  • Providing external access to a set of applications, hosted inside a corporate network. Represented in this architecture by external use applications.
  • Proving secure use to a set of applications, access from inside the network, but secured by Access Gateway. Represented by internal use applications.
  • Providing scalable managed access, using a variety of load balancers, located in strategic locations throughout the architecture.
  • Securing Kerberos based applications using Access Gateway and Okta's Kerberos support.
  • In-directing all internal network access using a proxy server.

Architecture

Components

Location

Component Description



External internet


Clients

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

Okta org

Your Okta org, providing identity services.

Okta org Universal Directory

Okta universal directory, housed within an Okta org, containing users outside other LDAP/AD implementations. Typically these include other customer accounts, partner accounts and more.




DMZ
Pre Access Gateway load balancer

Load balancer for the DMZ based cluster.
Positioned between internal clients and the internal use cluster.
See also About Access Gateway load balancing.

External useAccess Gateway cluster The Access Gateway cluster, located in the DMZ, 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 something similar. See Manage Access Gateway deployment.














Internal
External use Access Gateway admin The admin instance for the Access Gateway cluster located in the DMZ is typically located inside the internal network, and only accessible to administrators also inside the internal network.
Post external Load balancer Positioned between the external use Access Gateway cluster and the backing protected web resources, the post external load balancer manages load between Access Gateway and the protected web resources.
External use application External use applications are those protected web resources exposed by Access Gateway, but physically hosted within the internal network. These applications may be Header, Kerberos, SAML, SWA or other applications.
Internal clients Internal clients are users accessing applications from within the internal network itself. These clients are typically physically inside the customers network.
Pre internal Access Gateway load balancer

Load balancer for the DMZ based cluster.
Positioned between internal clients and the internal use cluster.
See also About Access Gateway load balancing.

Internal use Access Gateway cluster Internal use only Access Gateway cluster, completely separate from DMZ based Access Gateway cluster and used to provide access to internal use applications.
Internal Access Gateway load balancer Positioned between the internal use Access Gateway cluster and the backing protected web resources, the post internal load balancer manages load between Access Gateway and internal protected web resources.
See About Access Gateway load balancing.
Internal use applications Internal use applications are those protected web resources exposed by Access Gateway, but physically hosted within the internal network and only available to internal network clients
Active directory server(s) Internal use active directory servers used to support Kerberos applications are required.
Active directory agent(s) Co-located Okta active directory agents, configured to communicate via a proxy, and providing user information.

Other considerations

Not shown in this architecture are the data centers housing architecture components.
The following is a possible high level breakdowns of where different components are housed.

ComponentData center
External Access Gateway cluster.
Pre external Access Gatewayload balancer
Virtual data center 1
Likely AWS, OCI or MSAzure based
Post external Access Gateway load balancePhysical data center 1
Likely co-located with the internal use applications
Pre internal Access Gateway load balancerLikely virtual data center 2
Possibly co-located with either internal applications or internal Access Gateway
Internal Access Gateway clusterVirtual data center 2 (Possibly AWS etc, also possibly VMWare)
External use applications
Internal use applications
Physical data center 1

Internal proxy server

Possibly in Virtual data center 2, likely co-located with other internal servers.

Related topics

Common Access Gateway flows

About Access Gateway DNS use

About Access Gateway high availability

About Access Gateway prerequisites