CIAM  application reference architecture

Organizations focused on Customer identity access management (CIAM) architectures have distinct architectural considerations. CIAM infrastructures are typically built to accommodate a high number of users and requests to the applications. Applications are built out with multiple levels of redundancy and may be located in multiple data centers around the world in an active/active configurations. A typical architecture may include only a single application, multiple applications, or many applications, with different infrastructure requirements. Rather than shared infrastructure, typically each application has a separate stack for isolation and performance. In addition, there is often a requirement to let the users deeply into the application before requiring the user login or register.
In an Okta environment, CIAM users are typically stored in Universal Directory, instead of on premise LDAP, AD, or databases.

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 CIAM architectures

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

Single server The simplest of all architectures, the single Access Gateway server architecture is typical in development and test scenarios.
Single cluster The single cluster Access Gateway is an architecture representing the components required for protecting a single web resources using Access Gateway. This architecture extends the simple Access Gateway instance architecture by introducing an Access Gateway cluster.
Single split cluster The single split cluster Access Gateway is an architecture representing the components required for protecting multiple similar web resources using Access Gateway. This architecture extends the single cluster Access Gateway architecture by introducing an Access Gateway cluster split across multiple virtual environments.
Hybrid multi-cluster split The hybrid multi-cluster split Access Gateway is an architecture representing the components required for protecting multiple sets of web resources, with different requirements, using Access Gateway. This architecture combines the single cluster Access Gateway and single split cluster architecture by introducing an Access Gateway cluster split across clusters and multiple virtual environments.
Multi-cluster The multi-cluster Access Gateway architecture represents the components required for protecting multiple sets of web resources, with different requirements, using Access Gateway. This architecture extends the single cluster Access Gateway architecture by using multiple Access Gateway clusters distributed across multiple virtual environments.

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 simple CIAM application Access Gateway architecture represents a set of components required for protecting a single customer application web resource using Access Gateway.
This architecture represents a baseline or starting point for other architectures
In this architecture, a single application, referred to as protected web resource, is served to requesting clients using a single instance of Access Gateway.

This architecture is designed to meet the following requirements:

  • Protect a single customer application.
  • Provide a baseline for testing and development.

Benefits and drawbacks

Benefits Drawbacks
  • Simple installation
  • Baseline for testing, proof of concept etc.
  • Not fault tolerant
  • No load balancing or high availability
  • 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.

comsumer-app1.example.com
URLs not shown

URL representing 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

Access Gateway Access 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

 

Protected CIAM application The set of protected web resources, accessed using the comsumer-app1.internal-example.com URLs. 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 single cluster Access Gateway is an architecture representing the components required for protecting a single web resources using Access Gateway.
This architecture extends the simple Access Gateway instance architecture by introducing an Access Gateway cluster.

This architecture is designed to meet the following requirements:

  • Secure access to a single application - Accessible to the external internet.
  • 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 capacity
  • Load balanced
  • Single virtual environment
  • Pre Access Gateway DMZ based load balancer must support session affinity (sticky sessions)

 

Architecture

Components

Location

ComponentDescription

External internet

 

Web client

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.

Firewall

External internet to DMZ

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

 

 

 

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 Access Gateway load balancer

Balances load between clients and the Access Gateway cluster.
Positioned between clients and the 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.

comsumer-app1.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 application
The set of protected web resources, accessed using the consumer-app1.internal-example.com URLs. The traditional or historic application 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 single split cluster Access Gateway is an architecture representing the components required for protecting multiple similar web resources using Access Gateway.
This architecture extends the single cluster Access Gateway architecture by introducing an Access Gateway cluster split across multiple virtual environments.

This architecture is designed to meet the following requirements:

  • Secure access to multiple applications with similar loads - Accessible to the external internet.
  • 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
  • Supports multiple applications with varying loads
  • Provides basic fault tolerance and capacity support
  • Can be expanded with additional workers as required to add additional capacity
  • Load balanced
  • Complex
  • Multiple virtual environments
  • Requires multiple load balancers
  • Pre Access Gateway DMZ based load balancer must support session affinity (sticky sessions)

 

Architecture

Components

Location

ComponentDescription

External internet

 

Web client

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.

Firewall

External internet to DMZ

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

 

 

 

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 Access Gateway load balancer

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

Access Gateway environment one

Access Gateway instances, located in the DMZ, used to serve CIAM application 1.

Access Gateway environment twoAccess Gateway instances, located in the DMZ is used to serve CIAM application 2.
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 balancers

Multiple load balancers between the Access Gateway cluster and the protected applications.
Typically one per CIAM application.

comsumer-app1.example.com(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 application
The set of protected web resources, accessed using the consumer-app1.internal-example.com URLs. The traditional or historic application 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 hybrid multi-cluster split Access Gateway is an architecture representing the components required for protecting multiple sets of web resources, with different requirements, using Access Gateway.
This architecture combines the single cluster Access Gateway and single split cluster architecture by introducing an Access Gateway cluster split across clusters and multiple virtual environments.

This architecture is designed to meet the following requirements:

  • Secure access to multiple applications - Accessible to the external internet.
  • Provide support for applications with diverse and varying load conditions.
  • 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
  • Supports multiple applications, with varying needs.
  • Provides basic fault tolerance and capacity support
  • Can be expanded with additional workers as required to add additional capacity
  • Load balanced
  • Complex
  • Multiple virtual environments
  • Requires multiple load balancers
  • Pre Access Gateway DMZ based load balancer must support session affinity (sticky sessions)

 

Architecture

Components

Location

ComponentDescription

External internet

 

Web client

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.

Firewall

External internet to DMZ

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

 

 

 

Internal network

 

 

 

 

 

 

Pre Access Gateway load balancer

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

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.

Access Gateway environment one

Access Gateway instances, located in the DMZ, used to serve CIAM application 1.

Access Gateway environment twoAccess Gateway instances, located in the DMZ is used to serve CIAM application 2.

Access Gateway environment three

Access Gateway instances, located in the DMZ is used to serve CIAM application 3.
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 balancers

Multiple load balancers between the Access Gateway cluster and the protected applications.
Typically one per CIAM application or virtual environment

comsumer-app1.example.com(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 application
The set of protected web resources, accessed using the consumer-app1.internal-example.com URLs. The traditional or historic application 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 multi-cluster Access Gateway architecture represents the components required for protecting multiple sets of web resources, with different requirements, using Access Gateway.
This architecture extends the single cluster Access Gateway architecture by using multiple Access Gateway clusters distributed across multiple virtual environments.

This architecture is designed to meet the following requirements:

  • Secure access to multiple applications - Accessible to the external internet.
  • Provide support for applications, with diverse and varying load conditions, distributed over multiple areas or geographies.
  • 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
  • Supports multiple applications, with varying needs over multiple geographies
  • Provides basic fault tolerance and capacity support
  • Can be expanded with additional workers as required to add additional capacity
  • Load balanced
  • Very complex
  • Multiple virtual environments
  • Requires multiple load balancers
  • Pre Access Gateway DMZ based load balancer must support session affinity (sticky sessions)

 

Architecture

Components

Location

ComponentDescription

External internet

 

Web client

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.

Firewall

External internet to DMZ

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

 

 

 

Internal network

 

 

 

 

 

 

Pre Access Gateway load balancer

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

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.

Access Gateway environment one

Access Gateway instances, located in the DMZ, used to serve CIAM application 1 .

Access Gateway environment two

Access Gateway instances, located in the DMZ is used to serve CIAM application 2.

Access Gateway environment threeAccess Gateway instances, located in the DMZ is used to serve CIAM application 3 and 4.
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 balancers

Multiple load balancers between the Access Gateway cluster and the protected applications.
Typically one per CIAM application or virtual environment

comsumer-app1.example.com(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 application
The set of protected web resources, accessed using the consumer-app1.internal-example.com URLs. The traditional or historic application 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.