Workforce heterogeneous application reference architecture

Many workforce customers have a number of applications running inside the corporate network for their employees. These applications have been deployed over many years or even decades and can consist of home developed applications using various languages/platforms and also third party Commercial Off The Shelf (COTS) solutions. There may even be a current Web Access Management solution securing some or all of these applications. Applications may be capable of looking for HTTP headers, Windows Kerberos tokens, or SAML / oAuth tokens to identify the user. Applications may be deployed into HA clusters inside of multiple Datacenters using active/active active/passive(standby) or active/DR availability models.

Users may be stored in the corporate Active Directory, or in a separate LDAP Directory or database, or both. Users may be accessing the applications from a network located physically on the corporate network, virtually on the corporate network via a VPN connection, or over the internet.

Approach

To deploy Access Gateway to secure applications in an environment described above, it is best to begin deployment of a base architecture and then add specific features as needed. This methodology will allow an organization to begin moving forward in an agile fashion and not become overly bogged down in requirements analysis.

Key steps in determining an overall architecture include:

  • Identify which applications should be accessible through Access Gateway from the internet and which should require the user have access to the internal network. Typically this starts as a subset of applications, and expands over time.
  • Identify how applications are to be integrated with Okta and Access Gateway. Typical integrations include:
  • Identify how many users will access the applications and how often. This will help determine how many instances of Access Gateway are required, what number of load balancers are necessary and generally how the architecture components will be distributed.

Access Gateway workforce architectures

Access Gateway workforce installations can be deployed in any number of possible combinations. Common architecture are:

Single Access Gateway server architecture The simplest of all architectures, the single Access Gateway server architecture is typical in development and test scenarios.
Internal only single data center architecture The internal only single data center cluster expands on the single server architecture and introduces an Access Gateway cluster to extend capacity and provide fault tolerance, but for internal use only applications.
External only single data center architecture The external single data center cluster expands on the single server architecture and introduces an Access Gateway cluster to extend capacity and provide fault tolerance.
Multiple data center architecture The multi-data center Access Gateway architecture expands on both the single internal and external architecture but in a multiple data center environment with fault tolerance a both the Access Gateway and environment levels.

Comprehensive architecture

A comprehensive architecture showing all applications, but only as a single data center.

Architectures are broken down into the following functional areas:

External internet The external internet represents clients that access applications, as well as including your Okta Org.
DMZ The DMZ houses an Access Gateway cluster, and associated components, to allow access to applications from the external internet.
Internal The internal network houses the applications being protected by Access Gateway as well as other components required to make these applications widely available.

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.

Note

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 Prerequisites for deploying Access Gateway 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 something similar. See Manage Access Gateway deployment.
Firewall DMZ to internal internet Traditional firewall between DMZ 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.

Other considerations

DNS is typically split externally vs internally. All external URLs, such as [appN|comsumer-app1].example.com, would be served externally and point to the Access Gateway instance. Internal URLs, used by Access Gateway such as [protd-N|comsumer-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 for more information on configuring log forwarding.


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.

The internal Access Gateway is a single data center architecture representing the components required for protecting internal only access web resources using Access Gateway.
This architecture extends the single Access Gateway instance architecture by introducing an Access Gateway cluster. However it differs in that all components are deployed and accessed exclusively from within an internal network.

This architecture is designed to meet the following requirements:

  • Secure access to a set of internal use applications - Accessible only from the internal network.
  • Provide fault tolerance - Providing additional instances of Access Gateway, as cluster workers, such that if one is unavailable the cluster continues to perform normally.
  • Manage capacity - Providing additional instances of Access Gateway to handle expected load.

Benefits and drawbacks

BenefitsDrawbacks
  • Relatively simple installation
  • Provides basic fault tolerance and capacity support
  • Can be expanded with additional workers as required to add additional capacity
  • Load balanced
  • Single data center
  • Pre Access Gateway DMZ based load balancer must support session affinity (sticky sessions)
  • Requires a proxy to reach the outside internet

 

Architecture

Components

Location

ComponentDescription



External internet

 

Web client

Not applicable, there are no external use clients in this architecture.

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.

Firewall

External internet to DMZ

Traditional firewall between the external internet and the DMZ hosting Access Gateway.

 

 

 









Internal network

 

 

 

 

 

 

Internal clients

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

Proxy server

Internal proxy server. Proxying Access Gateway and internal client traffic to the external internet.
Access Gateway adminAccess Gateway admin node, in any of the data centers handling configuration, configuration backups, log forwarding and similar activities.
Access by administrators within the internal network.

Pre Access Gateway load balancer

Balances load between clients and the Access Gateway cluster.
Positioned between clients and the internal use Access Gateway cluster.

Access GatewayAccess 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 something similar. See Manage Access Gateway deployment.
Pre internal application load balancer

Balances load between the Access Gateway cluster and the protected applications.

appN.example.com
URLs not shown

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
URLs not shown
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.

Other considerations

DNS is typically split externally vs internally. All external URLs, such as [appN|comsumer-app1].example.com, would be served externally and point to the Access Gateway instance. Internal URLs, used by Access Gateway such as [protd-N|comsumer-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 for more information on configuring log forwarding.

Not shown in this architecture are the data centers housing architecture components.

The external Access Gateway in a one data center architecture representing the components required for protecting web resources using Access Gateway.
This architecture extends the single Access Gateway instance architecture by introducing an Access Gateway cluster.
In this architecture, a set of applications, referred to as protected web resources, are served to requesting clients using an Access Gateway cluster.

This architecture is designed to meet the following requirements:

  • Secure access to a set of applications - Accessed from the external internet, but housed within an internal network.
  • Provide fault tolerance - Providing additional instances of Access Gateway, as cluster workers, such that if one is unavailable the cluster continues to perform normally.
  • Manage capacity - Providing additional instances of Access Gateway to handle expected load.

Benefits and drawbacks

BenefitsDrawbacks
  • Relatively simple installation
  • Provides basic fault tolerance and capacity support
  • Can be expanded with additional workers as required to add additional capacity
  • Load balanced
  • Single data center
  • Pre Access Gateway DMZ based load balancer must support session affinity (sticky sessions)
 

Architecture

Components

Location

ComponentDescription





External internet

 

 

 

Web clients

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

appN.example.com
URLs not shown

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.

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.

Firewall

External internet to DMZ

Traditional firewall between the external internet and the DMZ hosting Access Gateway.




DMZ

 

Pre Access Gateway load balancer

Load balancer for the DMZ based Access Gateway cluster.
Positioned between outside clients and the external use Access Gateway cluster.

Access GatewayAccess Gateway cluster, 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 something similar. See Manage Access Gateway deployment.

Firewall

DMZ to internal firewall

Traditional firewall between DMZ and the internal network.

 




Internal network

 

Access Gateway adminAccess Gateway admin node, in any of the data centers handling configuration, configuration backups, log forwarding and similar activities.
Accessed by administrators within the internal network.
Pre internal Access Gateway load balancer

Load balancer for the DMZ based cluster.
Positioned between internal clients and the internal use cluster.

Protected applications
URLs not shown
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.

Other considerations

DNS is typically split externally vs internally. All external URLs, such as [appN|comsumer-app1].example.com, would be served externally and point to the Access Gateway instance. Internal URLs, used by Access Gateway such as [protd-N|comsumer-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 for more information on configuring log forwarding.

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 Gateway load 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.

The multiple data center Access Gateway architecture represents the set of components required to deploy Access Gateway in a high performing, fault tolerant multi-data center environment.

Typically this architecture is where active-active or active-warm standby data centers are required, although fail over can be provided at multiple levels in this architecture. As shown this architecture depicts an active-active configuration where each datacenter has fault tolerance built in. This architecture is for highly available applications where the application is configured to run in both datacenters at the same time.

This architecture is designed to meet the following requirements:

  • Providing secure access to a set of applications, accessed from the external internet, although a similar approach can be done for internal only accessible applications.

  • Support user access by data centers, selected by location, or other criteria to improve access rates

  • Provide a high level of performance, including fault tolerant load balancers both within each data center and across data centers (the app will remain accessible if any single component is lost inside the DC, or if an entire DC is not available)

  • Provide a high level of fault tolerance inside of each data center :

    • Load balancer level - one load balancer per data center at the Access Gateway and protected application levels
    • Access Gateway workers segmented by data center, with a single admin node
    • Protected web resources replicated at the data center level
BenefitsDrawbacks
  • Extremely fault tolerant
  • Extremely high performing
  • Provides failover at multiple levels or locations within the architecture
  • Complex
  • Additional hardware / virtual servers needed for redundancy

Architecture

Components

LocationComponentDescription





External internet
Web clients

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

appN.example.com
URLs not shown
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.

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.

Firewall

External internet to DMZ

Traditional firewall between the external internet and the DMZ hosting Access Gateway.




DMZ

Pre Access Gateway load balancers

Load balancers for the DMZ based Access Gateway cluster.
Potentially providing failover between data centers.

Access Gateway workersAccess Gateway instances, distributed in both data centers but sharing an administration instance.
Workers use DNS to select the appropriate protected web resources.

Firewall

DMZ to internal firewall

Traditional firewall between DMZ and the internal network.





Internal network 
Access Gateway adminAccess Gateway admin node, in any of the data centers handling configuration, configuration backups, log forwarding and similar activities.
Access by administrators within the internal network.

Pre internal Access Gateway load balancers

Load balancers between Access Gateway and the protected web resources.  
Potentially providing failover between data centers.

Protected applications
URLs not shown

The set of protected web resources, accessed using the protd-N.internal-example.com URLs.
Replicated set of highly available back end protected web resources.

Other considerations

Geographic or other load balancing techniques such as DNS round robin have been deployed to route session traffic to the different data centers. This data center routing should be “sticky” (session affinity) and route the user to the same data center for the life of the session or until a data center is no longer accessible.

 

SSL may be terminated on either the Load balancers or the Access Gateway servers themselves. if SSL is terminated on the Load balancers the communications from the LB to OAG must be over SSL, but a self signed certificate on Access Gateway may be used.

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 for more information on configuring log forwarding.

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

ComponentDescription




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 
External useAccess Gateway clusterThe 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 adminThe 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 balancerPositioned 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 applicationExternal 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 clientsInternal 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.

Internal use Access Gateway clusterInternal use only Access Gateway cluster, completely separate from DMZ based Access Gateway cluster and used to provide access to internal use applications.

Post 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.

Internal use applicationsInternal 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 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.