Architecture insight ​

Cloud-IAM’s architecture is built for high availability, security, and robustness, utilizing a multi-layered approach. While certain architectural details are proprietary and cannot be disclosed for security reasons, here is an overview of Cloud-IAM’s key architectural components and principles.

Cloud-IAM architecture insight ​

Cloud-IAM architecture is designed to ensure isolated and dedicated deployments, minimizing the risk of cross-tenant interferences and preserving performance integrity across environments.

Control plane ​

Cloud-IAM's ** Control Plane** consists of the Cloud-IAM Console, API, and a centralized database. This database securely stores customer information, organizational configurations, and associated deployment data. The Control Plane coordinates global settings and manages the Cloud-IAM resources across all customer deployments.

Data plane ​

Each Data Plane represents an individual customer deployment managed by Cloud-IAM. Data Planes operate autonomously, ensuring that customer environments remain functional even if there are issues within the Control Plane. This self-sufficiency allows for uninterrupted service and greater resilience.

Job execution and worker pool ​

The Control Plane initiates tasks by leveraging a distributed worker pool to execute operations within the Data Planes. This asynchronous job model ensures scalable and efficient interactions across multiple deployments while maintaining secure and isolated access.

Deployment architectures insight ​

Single region deployment ​

Cloud-IAM's single-region deployments are designed for reliability and are hosted within their own dedicated isolated network infrastructure. This deployment architecture provide a highly available Keycloak setup that is optimized for production-grade performance, ensuring robust and dependable identity management for mission-critical applications.

Key features of this architecture include:

• Dedicated VPC: Deployed across all availability zones in the chosen region.
• Fixed public gateway ip address: Outbound traffic is made through a single IP address. This IP is attached to the deployment and can be whitelisted in your infrastructure.
• Zone-Specific Network Restrictions: Ensuring secure and optimized traffic management.

This architecture is built to eliminate single points of failure. Every component is replicated at least once, ensuring seamless operation during failures or maintenance activities.

Highly available architecture:

• Load Balancing: Inbound traffic is distributed using DNS-based load balancers with integrated health checks.
• Self-Sufficient Nodes: Each Keycloak node operates independently, ensuring robust service availability.
• Multi-AZ Architecture: The deployment spans multiple availability zones, ensuring high availability and fault tolerance across the region.
• Database Replication: Databases are synchronized with failover capabilities for maximum resilience.
• Backups: Regular backups are stored in another region and cloud-provider, ensuring data durability and rapid recovery in case of a regional failure.

Multi-region Deployment ​

Cloud-IAM’s multi-region deployments are designed to enhance availability, resilience, and disaster recovery capabilities. This active-passive architecture, powered by AWS Cloud and leveraging Aurora technology for cross-region database replication, ensures that your identity management system remains highly available, even during regional outages.

In a multi-region Keycloak deployment, Keycloak clusters are deployed in separate regions, with one acting as the active cluster and the others as passive. These clusters are connected to synchronized databases, enabling real-time data exchange and maintaining data consistency and minimizing downtime.

State-of-art Architecture:

• Enhanced redundancy: By deploying clusters across multiple regions, this architecture ensures physical redundancy of your Keycloak and is data regional in case of outages or other catastrophic events.
• Seamless failover: In the event of an incident, this architecture allows to switch in few minutes to the secondary Keycloak cluster, without having to recreate a new cluster from the previous backup.
• Optimized user experience: With real-time data synchronization and active session persistence, users experience minimal downtime, even during a failover.
• Centralized management: One Keycloak instance is used to configure and manage all regions, providing a unified interface for seamless administration and monitoring of multiple clusters.

Data transfer ​

Even if your deployment are kept isolated from others, they are part of our overall infrastructure. That's why some data might be gathered in our monitoring systems.

This is the case of the deployment logs, deployment usage metrics that are aggregated in France.

Database snapshot are located in the deployment region, but the deployment cold backup are stored in France.

Also note that all the control plane is being hosted in France. That includes the deployment settings, organization members, deployment third party resources, deployment custom extensions.

Deployment lifecycle ​

The deployment is automatically managed by Cloud-IAM and its status is reflected in the Cloud-IAM Console.

When the deployment is in a normal state, it is marked as RUNNING.

Through the API or the Console, the customer can interact with the deployment. Some actions such as managing custom extensions, setting environment variables, ... require to restart the Keycloak cluster. This is smoothly done through a rolling upgrade over all the nodes of the cluster.

During this period, the deployment is marked as STARTING. For the end-user point of view, the rolling upgrade is transparent. However, the deployment in the Cloud-IAM data plane system is frozen until it is RUNNING again. This is done to ensure the deployment changes are applied atomically.

If, for any reason, during a rolling upgrade, the process could not complete, the deployment is marked as ERROR. This happens for instance, when a custom extension is not properly packaged, with missing classes, ... In this case, the process is interrupted and the deployment is blocked in this state.

Please note that even in the ERROR state, the Keycloak cluster might still be available. Usually, only one node of the cluster is missing and this error is seamless for the end-user.

In such case, please contact the support so that the Cloud-IAM support team helps to diagnose and heals the deployment.

Rolling upgrade ​

The rolling upgrade phase is when a change is applied to the cluster. To keep the cluster alive during all the operation, the nodes are sequentially removed from the cluster, upgraded, then re introduced into the cluster.

This is the safest way to upgrade a cluster by minimizing the risk. However, during this period, the cluster will run simultaneously 2 versions of the Keycloak settings with some nodes that have been updated, and others that will.

Be aware of that and respect the backward compatibility principles so that the nodes can continue sharing the same information (in the attributes, cache, database, ...) and that the services depending on it continue working properly.