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 6.5 or newer
  • OS X El Capitan or newer (for testing only)

All operating systems must run on x86 64-bit platforms.

Software Dependencies

  • Libcrypto v. 1.1.X (included with OpenSSL or libSSL)

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, 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
  • 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


When the system is deployed in production environments it’s recommended to use a separate Network Interface for configuration and replication of configuration. 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. This port should only be open on the internal network, and not open to the Internet.

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
2024 SSH accessed from admin workstations
6749 Admin API accessed from admin workstations

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). 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.