Go-live Checklist

Before deploying the Curity Identity Server into a production environment (which is any where sensitive data, even valuable test data, may be used), make sure and complete the following checklist.

General System

  • Disable SSH access on the system hosting Curity Identity Server, unless you plan to use the Curity command-line interface (CLI)
  • Disable the REST API if that won’t be used in production
  • Disable the GUI if that won’t be used in production
  • Ensure that all SSL certificates are signed by a trusted Certificate Authority (CA)
  • Check that keys with different purposes are different. Do not mix them.
  • Set logging to INFO level
  • Check that the license is valid and will not expire in the near future
  • Ensure that each Curity admin staff member has their own account with a strong password
  • Be sure that janitor procedures have been setup in the database to cleanup old sessions, tokens, etc.
  • Check that examples and non-production apps (like the UI Builder) are not deployed

All Profile Types

  • Ensure that unused endpoints are not deployed to any node; optionally, they can be removed from each respective profile.
  • Make sure that any procedures (for token issuance, attribute transformation, introspection, event listeners, etc.) are not logging any sensitive or excessive information and are returning the least required information in their results
  • Ensure that only the required event listeners are configured


  • Ensure that no unused authenticators are defined
  • Ensure that no unused apps (i.e., service providers) are configured
  • If account linking isn’t used, be sure that it is disabled for all authenticators
  • Make sure that the redirect whitelist is not set to * and is as restrictive as possible

Token Service

  • Ensure that any OAuth profile has only the required capabilities enabled
  • Ensure that no apps (i.e., clients) are configured that are not used or at least that unused ones are disabled
  • Remove all unused scopes
  • If OAuth metadata isn’t used, be sure it is disabled
  • If Dynamic Client Registration (DCR) isn’t needed, be sure it is disabled

User Management

  • Be sure that an authorization manager is defined or appropriate network security is in place to restrict access to the SCIM endpoint


  • Consider if production config should be encrypted. Re-encrypt config and distribute keys to production nodes. See Encrypted Configuration.


  • Make sure the cluster is part of the init xml configuration files
  • Make sure that a different cluster key is used for the production cluster than what was used in pre-prod.