Single split cluster CIAM application reference architecture
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 thesingle 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
|External internet||Web client||
Traditional client browser accessing Access Gateway using known as [appN|consumer-app1].example.com URLs.
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.
External internet to DMZ
|Traditional firewall between the external internet and the DMZ hosting Access Gateway.|
|Access Gateway admin||Access 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.
|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.
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||Access Gateway as a load balancer between Access Gateway cluster and the protected applications.
Configured per CIAM application.
See About Access Gateway load balancing.
|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.|
DNS is typically split externally vs internally. All external URLs, such as [appN|consumer-app1].example.com, would be served externally and point to the Access Gateway instance. Internal URLs, used by Access Gateway such as [protd-N|consumer-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.