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:
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
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 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 Role | Zone | Data Source | Instances |
---|---|---|---|
Europe | eu | European Database | 1, 2 |
USA | us | USA Database | 3, 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