Access

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, see scanInterval in Router.

Disable administration endpoints and Studio by setting the IG run mode to 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.

Update patches

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.

Manage cookies

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 secure flag to ensure that browsers cannot transmit the cookie over non-SSL.

When cookies have the secure flag, 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 httpOnly flag, to ensure that the cookie cannot be accessed through client-side scripts, and to mitigate any cross-site scripting attacks.

Cookies are httpOnly by default in admin.json, JwtSession, CrossDomainSingleSignOnFilter, and FragmentFilter. In web container mode, check WEB-INF/web.xml. For more information, see Configuring stateful sessions.
Set the samesite attribute of cookies to STRICT or 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.cookie property in admin.json.
For stateful sessions in web container mode, configure the container WEB-INF/web.xml file when you unpack the IG .war file. For more information, see Configuring stateful sessions.
For stateless sessions, configure the cookie property of JwtSession.
For authentication results, configure the authCookie property of CrossDomainSingleSignOnFilter.
For the fragment part of a URI when a request triggers a login redirect, configure the cookie property of FragmentFilter.

Identity Gateway 7.2