Identity Gateway 2024.3

Secure and harden

The following sections describe options for securing and hardening your deployment:

General security considerations

Consider the following settings in IG to secure your deployment:

Switch to production mode.

Prevent changes to your configuration by setting the run mode to production. For information, refer to Operating modes.

Protect endpoints.

Restrict access to your monitoring data by protecting the Prometheus Scrape Endpoint and Common REST Monitoring Endpoint (deprecated). Learn more from Protecting the monitoring endpoints.

Exclude sensitive data from logs.

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

  • 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 amount of information available to attackers during reconnaissance, the initial phase of an attack sequence.

  • Reduce the global log level from TRACE or DEBUG to INFO. For information, refer to Changing Log Levels.

  • Avoid using words that help to identify IG in error messages, such as those produced by the entity in a StaticResponseHandler. For information, refer to StaticResponseHandler.

Secure responses from cross-site scripting.

  • Sanitize any external input, such as the request, before incorporating it in the response.

  • Specify Content-Type in the headers property of StaticResponseHandler when an entity is used. (Required by default, from IG 7.)

  • Set the response header X-Content-Type-Options: nosniff to prevent the user agent from interpreting the response entity as a different content type. (Set by default, from IG 7.)

  • Set a restrictive value in the Cache-Control response header. For example, setting Cache-Control: private indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache.

Secure sessions.

Protect network traffic by using HTTPS where possible, and secure communications during stateless sessions by signing and encrypting JWTs. For information, refer to JwtSession.

Secure cookies.

  • Store a minimum amount of sensitive data in cookies, and only when necessary.

  • Change the default name of cookies to prevent them from being easily associated with an application.

  • Where possible, configure cookie properties to restrict how and where they can be used. For more information, refer to cookie in JwtSession, and authCookie in CrossDomainSingleSignOnFilter.

Consider the following general points to secure your deployment:

Keep up-to-date on patches.

Security vulnerabilities are the reason why you should keep your operating systems, web and application servers, and any other application in your environment up-to-date. Knowledge of vulnerabilities spreads fast across malicious users, who would not hesitate in trying to exploit them.

Ping Identity maintains a list of security advisories you should follow. You should also follow similar lists from all of your vendors.

Keep up-to-date on cryptographic methods and algorithms.

Different algorithms and methods are discovered and tested over time, and communities of experts decide which are the most secure for different uses. Do not use outdated algorithms for generating your keys.

Turn off unnecessary features.

The more features you have turned on, the greater the attack surface. If something is not being used, uninstall it, disable it, or protect access to it.

Limit access to the servers hosting IG.

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

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

Enforce security.

Do not expect your users to follow security practices on their own; enforce security when possible by requiring secure connections, password resets, and strong authentication methods.

Audit access and changes.

Audit logs record all events that have happened. Some applications store them with their engine logs, others use specific files or send the information to a different server for archiving. Operating systems have audit logs as well, to detect unauthorized login attempts and changes to the software.

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

Prevent log flow attacks.

Limit the number of repeat log messages by adding a custom logback.xml with a DuplicateMessageFilter. For information, refer to Limit Repetitive Log Messages.

Switch from development mode to production mode

After installation, IG is by default in production mode. While you evaluate IG or develop routes, it can be helpful to switch to development mode as described in Operating modes. However, after deployment it’s essential to switch back to production mode to prevent unwanted changes to the configuration.