System Requirements

The Curity Identity Server is a Linux based server that can run on most standard Linux distributions, however the following are tested and supported:

Operating Systems

  • Ubuntu Server 14.04 LTS or newer
  • CentOS 8 or newer
  • macOS (El Capitan or newer for testing only)[1]

All production operating systems must run on x86 64-bit platforms and, on Linux, GNU C Library version 2.25 or newer is required.

ARM based macOS requires Rosetta II to be installed.

Minimum Hardware Requirements

  • 4 Core CPU, 2.4GHz (x86_64 architecture)
  • 4 GB RAM
  • 15 GB Hard drive
  • 1 dedicated NIC

Hypermedia Authentication API

All mobile devices that consume the hypermedia authentication API must be running the following operating systems (or newer):

  • iOS 14
  • Android 8.0 (Oreo, API level 26)


Only the latest versions of Chrome, Firefox, Safari, Samsung[2] and Edge are supported on the latest versions of macOS, Windows, iOS, and Android. Older versions of those or other platforms (e.g., Linux) are supported on a best-effort basis. No other browsers (e.g., Brave, Opera, IE, etc.) are supported on any platform. The only supported browsers for use with the admin Web UI are the latest versions of Chrome, Firefox, and Edge on the latest version of Windows and macOS. No other browser on any platform is supported (though they may work).


For storing tokens, session information, etc., a database is required. Follow the hardware recommendations of your database vendor. The hard drive size that should be used depends on if you are using the Curity Security Token Server or if you are only using the Curity Authentication Server. In the former case, 100-150 GB is recommended. If only the Curity Authentication Server is used, then 50 GB is suggested.

The following databases are supported:

  • MariaDB
  • MySQL
  • Amazon Relational Data Services (RDS)
  • Amazon Aurora
  • Amazon DynamoDB
  • Microsoft SQL Server
  • Azure SQL Database
  • Oracle (version 12 and above)
  • PostgreSQL
  • HSQLDB (for testing and development purposes only)
  • CockroachDB

User Repositories

The Curity Identity Server can integrate with numerous kinds of repositories for authenticating users and clients. It does not store any accounts itself. To support authentication, the Curity Identity Server can retrieve user identity data from any of the following:

  • All of the databases listed above
  • LDAP
    • Active Directory Domain Services (AD DS)
    • OpenLDAP
    • ApacheDS
    • UnboundID (in-memory directory server for testing and development purposes only)
  • SCIM
    • SCIM 1.1
    • SCIM 2.0


Each node is initialized with a file. This file contains the information for the server to be able to connect to the admin node. Such as HOST address and PORT. By default the Admin service will listen to on port 6789.

A run-time node can be configured to listen on any port. Access to this port from the user’s browser is typically required. By default, this is port 8443.

For administration, the following ports may also need to be open:

Port Description
4464 Alarm receiver endpoint
4465 Health check endpoint
4466 Prometheus-compliant metrics endpoint
6749 Admin API accessed from admin workstations

When the system is deployed in production environments, it’s recommended to use a separate network for the run-time port and another network for administrative ports.

The only supported encryption algorithm for signing keys, signature verification keys, SSL, etc. is RSA. Elliptic curve and DSA are currently unsupported.

Hardware Security Module

The only Hardware Security Modules (HSMs) that are supported are those that provide a PKCS#11 interface and are compatible with the Java Cryptography Extension (JCE). This means that every private key must be coupled with an X.509 certificate; keys without certificates are inaccessible and unusable. Only one HSM can be configured and that HSM must be configurable using just one PKCS#11 slot. Public key operations (e.g., encryption and signature verification) are not supported; instead, public keys should be uploaded into the configuration database.

File Encoding

The operating system must support the UTF-8 encoding scheme. Templates, message files, assets (e.g., CSS style sheets, JavaScript files), and other files must be encoding in UTF-8; no other encoding is supported even though others (like Latin-1) may work without issue.


Only HTTP 1.1 and 2.0 are supported. HTTP 1.0 is not supported.


Only TLS 1.2 and 1.3 are supported. Even if older versions can be enabled, they are not supported and may not work as intended.

[1]ARM is supported on M1 chips with macOS only. Docker containers using the ARM architecture are only supported for non-production usage on macOS running on an ARM CPU.
[2]The Samsung Browser is only supported for the Android operating system.