Install and run IG from a dedicated service account. This is optional when evaluating IG, but essential in production installations. For more information, refer to Create an IG service account.

Make sure only authorized people can access your servers and applications through the appropriate network, using the appropriate ports, and by presenting strong-enough credentials.

Apply the principle of least privilege to IG logs and configuration directories. For more information, refer to Configuration location.

Make sure that users connect to systems through the latest versions of TLS, and audit system access periodically.

Restrict access to your monitoring data by protecting the Prometheus Scrape Endpoint and Common REST Monitoring Endpoint. For information, refer to Protecting the monitoring endpoints.

Prevent IG from scanning for changes to routes. For information, see scanInterval in Router.

Disable administration endpoints and Studio by setting the IG run mode to production. For information, refer to Operating modes.

The more features you have turned on, the greater the attack surface. If something isn’t used, uninstall it, disable it, or protect access to it.

Prevent the exploitation of security vulnerabilities by using up-to-date versions of IG and third-party software.

Review and follow the Ping Identity security advisories.

Follow similar lists from all of your vendors.

Increase the security of cookies genrated by IG or the protected application in the following ways:

Harden an IG configuration by configuring the following objects:

Prevent the exploitation of security vulnerabilities by using up-to-date versions of IG and third-party software.

Review and follow the Ping Identity security advisories.

Follow similar lists from all of your vendors.

The initial phase of an attack sequence is often reconnaissance. Limit the amount of information available to attackers during reconnaissance, as follows:

When using a StaticResponseHandler, secure responses from cross-site scripting attacks, as follows:

Despite efforts to improve how people manage passwords, users have more passwords than ever before, and many use weak passwords. You are strongly encouraged to use a password manager to generate secure passwords. You can use identity and access management services to avoid password proliferation, and you can ensure the safety of passwords that you cannot eliminate.

Manage passwords for server administration securely. Passwords supplied to IG can be provided in files, through environment variables, or as system property values. Choose the approach that is most appropriate and secure for your deployment.

Misconfiguration can arise from bad or mistaken configuration decisions, and from poor change management. Depending on the configuration error, features can stop working in obvious or subtle ways, and potentially introduce security vulnerabilities.

The following behaviour can be caused by misconfiguration:

To guard against bad configuration decisions, implement good change management:

Data theft can occur when access policies are too permissive, and when the credentials to gain access are too easily cracked. It can also occur when the data is not protected, when administrative roles are too permissive, and when administrative credentials are poorly managed.

Threats can arise when plans fail to account for outside risks. To mitigate risk, develop appropriate answers to at least the following questions:

For critical services, test expected operation and disaster recovery operation.

Over the lifetime of a deployment, the operating system might be subject to vulnerabilities. Some vulnerabilities require system upgrades, whereas others require only configuration changes. All updates require proactive planning and careful testing.

For the operating systems used in production, put a plan in place for avoiding and resolving security issues. The plan should answer the following questions:

Software providers often do not communicate what they know about a vulnerability until they have a way to mitigate or fix the problem. Once they do communicate about security issues, the information is likely to become public knowledge quickly. Make sure you can expedite resolution of security issues.

To resolve security issues quickly, make sure you are ready to validate any changes that must be made. When you validate a change, check that the fix resolves the security issue. Validate that the system and IG software continue to function as expected in all the ways they are used.

System audit logs make it possible to uncover system-level security policy violations that are not recorded in IG, such as unauthorized access to IG files. Such violations are not recorded in IG logs or monitoring information.

Also consider how to prevent or at least detect tampering. A malicious user violating security policy is likely to try to remove evidence of how security was compromised.

By default, operating systems include many features, accounts, and services that IG software does not require. Each optional feature, account, and service on the system brings a risk of additional vulnerabilities. To reduce the surface of attack, enable only required features, system accounts, and services. Disable or remove those that are not needed for the deployment.

The features needed to run and manage IG software securely include the following:

Consider the minimal installation options for your operating system, and the options to turn off features.

Consider configuration options for system hardening to further limit access even to required services.

For each account used to run a necessary service, limit the access granted to the account to what is required. This reduces the risk that a vulnerability in access to one account affects multiple services across the system.

Make sure you validate the operating system behavior every time you deploy new or changed software. When preparing the deployment and when testing changes, maintain a full operating system with IG software that is not used for any publicly available services, but only for troubleshooting problems that might stem from the system being too minimally configured.

Server protocols such as HTTP, LDAP, and JMX rely on TLS to protect connections. To enforce secure communication, configure TLS as follows:

When negotiating connection security, the server and client must use a common security protocol and cipher suite. In ClientTlsOptions and ServerTlsOptions, define lists of security protocols and cipher suites. For security, use the most recent protocols and ciphers that the client supports. Clients with older TLS implementations might not support the most recent protocols and ciphers.

IG uses the Commons Secrets API to manage secrets, such as passwords and cryptographic keys.

Repositories of secrets are managed through secret stores, provided to the configuration by the SecretsProvider object or secrets object. For more information about these objects and the types of secret stores provided in IG, refer to SecretsProvider and Secrets.

The examples in this doc set use self-signed certificates, but your deployment is likely to use certificates issued by a certificate authority (CA certificates).

The way to obtain CA certificates depends on the certificate authority that you are using, and is not described in this document. As an example, refer to Let’s Encrypt.

Integrate CA certificates by using secret stores:

For examples, refer to Serve the same certificate for TLS connections to all server names.

Note the following points about using secrets:

For information about secret stores provided in IG, refer to Secrets.

IG validates the signature of signed tokens as follows:

For examples where a StatelessAccessTokenResolver uses a secret store to validate the signature of signed tokens, refer to the example sections of JwkSetSecretStore and KeyStoreSecretStore.

When multiple secrets stores are provided in a configuration, the secrets stores are queried in the following order:

Secrets stores defined in admin.json can be accessed only by heap objects in admin.json.

When the Elliptic Curve Digital Signature Algorithm (ECDSA) is used for signing, and both of the following conditions are met, JWTs are signed with a deterministic ECDSA:

Otherwise, when ECDSA is used for signing, JWTs are signed with a non-deterministic ECDSA.

A non-deterministic ECDSA signature can be verified by the equivalent deterministic algorithm.

For information about deterministic ECDSA, refer to RFC 6979. For information about Bouncy Castle, refer to The Legion of the Bouncy Castle.

Different algorithms and methods are discovered and tested over time, and communities of experts decide which are the most secure for different uses. Use up-to-date cryptographic methods and algorithms to generate keys.

Small keys are easily compromised. Use at least the recommended key size.

In JVM, the default ephemeral Diffie-Hellman (DH) key size is 1024 bits. To support stronger ephemeral DH keys, and protect against weak keys, consider setting the following system property to increase the DH key size: jdk.tls.ephemeralDHKeySize=2048. From Tomcat 8.5.37, the default DH key size is 2048-bit.

For more information, refer to Customizing size of ephemeral Diffie-Hellman keys

Rotate keys regularly to:

For more information, refer to Rotate keys.

Audits in IG record access to a route. Audit logs in operating systems detect system login attempts and changes to the software.

The IG audit logging service adheres to the log structure common across the ForgeRock Identity Platform. For information, refer to Audit the deployment.

Prevent logging of sensitive data for audit events by excluding fields from the audit logs. For information, refer to Including or excluding audit event fields in logs.

Logs in IG contain informational, error, and warning events, to troubleshoot and debug transactions and events that take place within the IG instance.

Protect logs from unauthorised access, and make sure they contain a minimum of sensitive or personally identifiable information that could be used in attacks.

When using a CaptureDecorator, mask captured header and attribute values to avoid disclosing information, such as token values or passwords. For information, refer to CaptureDecorator.

Limit the number of repeat log messages to prevent log flow attacks, by adding a custom logback.xml with a DuplicateMessageFilter. For information, refer to Limit repetitive log messages.