/images/resources/tutorials/concepts/concepts-deployment.png

Deployment Concepts

On this page

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:

RoleNumber of InstancesResponsibilities
Admin1Managing updates to configuration and then pushing the new configuration to runtime nodes
RuntimeMultipleReceiving 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

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.

Profiles

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 service role can run a particular set of profiles. Each Identity Server instance is assigned a single service role when it starts. Service roles can map to zones that use distinct databases, like in the following example.

Service RoleZoneData SourceInstances
EuropeeuEuropean Database1, 2
USAusUSA Database3, 4

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.

Join our Newsletter

Get the latest on identity management, API Security and authentication straight to your inbox.

Start Free Trial

Try the Curity Identity Server for Free. Get up and running in 10 minutes.

Start Free Trial