The following sections describe how to prevent unwanted access to your deployment, and reduce the amount of non-essential information that it provides.
Use an IG service account
Install and run IG from a dedicated service account. This is optional when you are evaluating IG, but essential in production installations. For more information, see Create an IG service account.
Remove non-essential access
Make sure that 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, see Set up logs and configuration files.
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, see Protecting the monitoring endpoints.
Prevent IG from scanning for changes to routes. For information,
scanInterval in Router.
Disable administration endpoints and Studio by setting the IG run
production. For information, see
Switching from development mode to production mode.
Remove non-essential 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.
Prevent the exploitation of security vulnerabilities by using up-to-date versions of IG and third-party software.
Review and follow the ForgeRock Security Advisories. To receive email notifications for new security advisories, log in to Backstage, and click the Subscribe button for agent 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:
Change the default name of cookies to prevent them from being easily associated with an application.
Create cookies with the
secureflag to ensure that browsers cannot transmit the cookie over non-SSL.
When cookies have the
secureflag, the first hop of the connection between the user agent and protected application must be secure (over HTTPs); subsequent hops do not have to be secure. In this example, the first hop from the user agent to NGINX is secure, the subsequent hop to IG is not secure:
User agent -> NGINX (https://acme.com) -> IG (http://gateway:8080)-> protected application (https://internal.app:8081)
Create cookies with the
httpOnlyflag, to ensure that the cookie cannot be accessed through client-side scripts, and to mitigate any cross-site scripting attacks.
httpOnlyby default in
admin.json, JwtSession, CrossDomainSingleSignOnFilter, and FragmentFilter. In web container mode, check
WEB-INF/web.xml. For more information, see Configuring stateful sessions.
samesiteattribute of cookies to
LAX. For more information, see SameSite cookies.
Set a timeout for cookies, to strike a good compromise between security and usability.
Harden an IG configuration by configuring the following objects:
For stateful sessions in standalone mode, configure the
session.cookieproperty in admin.json.
For stateful sessions in web container mode, configure the container
WEB-INF/web.xmlfile when you unpack the IG .war file. For more information, see Configuring stateful sessions.
For stateless sessions, configure the
cookieproperty of JwtSession.
For authentication results, configure the
authCookieproperty of CrossDomainSingleSignOnFilter.
For the fragment part of a URI when a request triggers a login redirect, configure the
cookieproperty of FragmentFilter.