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. |
| 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. |
|
| 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 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.
| Component | Data 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 balance | Physical data center 1 Likely co-located with the internal use applications |
| Pre internal Access Gateway load balancer | Likely virtual data center 2 Possibly co-located with either internal applications or internal Access Gateway |
| Internal Access Gateway cluster | Virtual 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. |