A clustered deployment of the Curity Identity Server to a single region is a fairly straightforward task. Companies often want to go beyond this, however, to span multiple regions and organizational divisions. This article summarizes options for taking finer control over behavior when needed.
The Identity Server is designed to run in containers in any cloud, though it can also be hosted via on-premise servers if needed. For the best options, we recommend using a platform such as Kubernetes, with built-in features for auto-healing and auto-scaling.
Each instance of the Curity Identity Server is either an admin or a runtime node:
|Role||Number of Instances||Responsibilities|
|Admin||1||Managing updates to configuration and then pushing the new configuration to runtime nodes|
|Runtime||Multiple||Receiving authentication, token, and user management requests from OAuth clients, the Reverse Proxy and APIs|
Runtime nodes are designed to be deployed in the following manner, where configuration drives the deployment. Once deployed, the runtime nodes should then always be in a working state:
- They are deployed with the latest configuration backup
- They never call each other and share state via a database
- They receive future configuration updates from the admin node
Profiles provide working functionality to handle either Authentication, Token, or User Management requests. It is possible to define multiple copies of each of the three services with different behavior. An ‘external’ profile might be used to provide only a subset of OAuth endpoints to internet clients.
Zones are commonly used with Multi Region Deployments to assign identifiers for each region. Zones can be mapped to data sources to ensure the stored User Data is always stored in the user’s home region.
A Service Role is a string name to represent a particular set of servers. Each Identity Server instance is assigned a single service role when it starts. Service roles can map to zones in the following manner:
|Service Role||Zone||Data Source||Instances|
|Europe||eu||European Database||1, 2|
|USA||us||USA Database||3, 4|
Profiles, Service Roles and Zones can be used to enable advanced deployments, such as to provide a Multi Tenant OAuth solution for business partners or subdivisions.
A cluster is the collection of all runtime nodes, which could be hosted in the same Datacenter or multiple Datacenters. The runtime nodes in a cluster are independent of each other and are designed to scale horizontally.
It is common to use a single backup of the system’s Configuration XML regardless of the deployment design. This avoids duplication of OAuth client settings and potential reliability problems in applications.
Customers will need to periodically Upgrade the Identity Server, and this is designed to be a straightforward operation:
- Read the release notes, then upgrade databases and configuration if needed
- Prepare a new custom Docker image from the new base image
- Copy in Login UX branding customization, plugins, parameterized configuration, and other resources
- Upgrade the admin node first
- Then upgrade runtime nodes in a phased manner
Real-world deployments of Identity and Access Management systems can be challenging. So, Curity provides you with a toolbox for designing your own deployments. The system must then run reliably over time. On that note, operational aspects are summarized in the Availability Concepts article.
Let’s Stay in Touch!
Get the latest on identity management, API Security and authentication straight to your inbox.