IG 7.1.2

Securing and Hardening

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, see Switching From Development Mode to Production Mode.

Protect endpoints.

Restrict access to your monitoring data by protecting the Prometheus Scrape Endpoint and Common REST Monitoring Endpoint. For information, see 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, see 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, see 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, see 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, see 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, see 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, see cookie in JwtSession, and authCookie in CrossDomainSingleSignOnFilter.

Protect against weak DH keys.

In JVM, the default ephemeral Diffie-Hellman (DH) key size is 1024 bits. To support stronger ephemeral DH keys, and protect against weak keys, installations in Tomcat 8.5.37 and later versions use the Tomcat default DH key size of 2048-bit.

For IG installations in Jetty or JBoss, consider setting the following system property to increase the DH key size: jdk.tls.ephemeralDHKeySize=2048.

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.

ForgeRock maintains a list of security advisories that 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 more features you need to secure, patch, and audit. If something is not being used, disable it or uninstall 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, see Auditing Your Deployment.

Prevent log flow attacks.

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

Switching From Development Mode to Production Mode

IG operates in development mode and production mode, as defined in Development Mode and 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 Switching from Production Mode to Development Mode. However, after deployment it is essential to switch back to production mode to prevent unwanted changes to the configuration.

Switch From Development Mode to Production Mode

  1. In $HOME/.openig/config/admin.json (on Windows, appdata\OpenIG\config ), change the value of mode from DEVELOPMENT to PRODUCTION:

    {
  "mode": "PRODUCTION"
}

    The file changes the operating mode from development mode to production mode. For more information about the admin.json file, see AdminHttpApplication (admin.json).

    The value set in admin.json overrides any value set by the configuration token ig.run.mode when it is used in an environment variable or system property. For information about ig.run.mode, see Configuration Tokens.

  2. Prevent routes from being reloaded after startup:

    1. To prevent all routes in the configuration from being reloaded, add a config.json as described in the Getting Started, and configure the scanInterval of the main router.

    2. To prevent individual routes from being reloaded, configure the scanInterval of the routers in those routes.

      {
  "type": "Router",
  "config": {
    "scanInterval": "disabled"
  }
}

      For more information, see Router.

  3. Restart IG.

    When IG starts up, the route endpoints are not displayed in the logs, and are not available. You can’t access Studio on http://openig.example.com:8080/openig/studio.

Copyright © 2010-2023 ForgeRock, all rights reserved.