Network connections
Protect network traffic by using HTTPS where possible, and secure communications during stateless sessions by signing and/or encrypting JWTs. For information about configuring IG for HTTPS client-side and HTTPS server-side, refer to the Installation guide.
Protocol | Recommendations |
---|---|
HTTP |
HTTP connections that are not protected by SSL/TLS use cleartext messages. When you permit insecure connections, you cannot prevent client applications from sending sensitive data. For example, a client could send unprotected credentials in an HTTP Authorization header. Even if the server were to reject the request, the credentials would already be leaked to any eavesdroppers. Always use HTTPS for connections up to a load-balancer or proxy in front of the web application or server. |
HTTPS |
Follow industry-standard TLS recommendations for Security/Server Side TLS. Use a secure version of TLS/SSL to connect to TLS-protected endpoints with HTTP connection handlers, such as ClientHandler and ReverseProxyHandler. TLS protocols below 1.2 aren’t considered secure. Some client applications require a higher level of trust, such as clients with additional privileges or access. Client application deployers might find it easier to manage public keys as credentials than to manage user name/password credentials. Client applications can use SSL client authentication. When using IG REST to LDAP gateway, use HTTPS to protect client connections. |
JMX |
Secure JMX access with the SSL/TLS-related properties, such as |
SSH |
IG administration tools can connect securely. Administrators should use SSH when changing the IG configuration or binaries. The user account for running IG should not be the same user account for connecting remotely. Secure Copy (SCP) uses SSH to transfer files securely. SCP is an appropriate protocol for copying backup data, for example. |
Client | Recommendations |
---|---|
Common Audit event handlers |
Configure ForgeRock Common Audit event handlers to use HTTPS when connecting to external log services. |
OAuth 2.0-based HTTP authorization mechanisms |
HTTP authorization can be based on OAuth 2.0, where IG servers act as resource servers, and make requests to resolve OAuth 2.0 tokens. Use HTTPS to protect the connections to OAuth2ResourceServerFilter and AuthorizationCodeOAuth2ClientFilter. For information, refer to OAuth2ResourceServerFilter and AuthorizationCodeOAuth2ClientFilter. |
Message-level security
Server protocols such as HTTP and JMX rely on TLS to protect connections. To enforce secure communication, configure TLS as follows:
-
HTTPS server-side: Configure admin.json, Configure IG for HTTPS (server-side).
-
HTTPS client-side: Configure trust managers and key managers, as described in Configure IG for HTTPS (client-side).
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.