Deployment Concepts

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.

Deploy Anywhere

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.

Nodes

Each instance of the Curity Identity Server is either an admin or a runtime node:

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

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

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.

Service Roles

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:

Multi-tenancy

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.

Clusters

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.

Configuration

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.

Upgrades

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

Conclusion

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.