Simple CIAM application reference architecture

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.

Related topics

Common Access Gateway flows

About Access Gateway DNS use

About Access Gateway high availability

About Access Gateway prerequisites