Plan for security in Identity Cloud

Always use HTTPS for connections into Identity Cloud.

Identity Cloud does not accept connections over HTTP. However, a client making API calls to Identity Cloud over HTTP instead of over HTTPS can still send unprotected credentials in an HTTP Authorization header, inadvertently exposing sensitive information. Even though Identity Cloud rejects the request, the credentials could be leaked to eavesdroppers.

Configure the cookie domain in your Identity Cloud tenant to ensure only users and entities from trusted domains can be authenticated.

By default, Identity Cloud sets the cookie domain based on the fully qualified hostname of a tenant, such as id.mycompany.co.uk. However, you may want to change the cookie domain to mycompany.co.uk so Identity Cloud can communicate with any subdomain.

Refer to Configure the cookie domain for a custom domain.

Configure cross-origin resource sharing (CORS) to securely share browser resources across domains.

In Identity Cloud, you can configure CORS to allow browsers from trusted domains to access Identity Cloud protected resources. You can create as many individual CORS configurations as your applications need. The configurations combine to form the entire set of rules for resource sharing. The CORS service also collects the values of the JavaScript Origins property in each OAuth 2.0 client and adds them to the list of accepted origins.

Refer to Configure CORS.

Identity Cloud includes a filter to harden protection against cross-site request forgery (CSRF) attacks. The filter applies to all REST endpoints under /am/json/. It requires all requests other than GET, HEAD, or OPTIONS to include at least one of the following headers:

Failure to include at least one of the headers causes the REST request to fail with a 403 Forbidden error.

For more information about API versioning, refer to REST API versions.

To protect against requests that contain large amounts of data, Identity Cloud rejects the following:

ForgeRock provides policy enforcement points (PEPs) to improve application security by enforcing Identity Cloud authentication and authorization decisions in your applications:

Refer to these guides:

For applications built using an SDK, refer to the Security guide for SDKs.

To minimize the time an attacker has to attack an active session, set expiry times for Identity Cloud sessions and JWT tokens.

ForgeRock recommends setting an expiry time of 15 minutes. However, you should decide your expiry time according to the context of your deployment, balancing security and usability so that your end users can complete operations without their sessions frequently expiring. For more information, refer to the OWASP Session Management Cheat Sheet.

To update the expiry time for sessions and JWT tokens in Identity Cloud, refer to Configure session termination settings.

Enable authentication session allowlisting to protect authentication sessions from replay attacks, whereby a malicious user might try to rewind an authentication flow to a previous node.

Refer to Authentication session allowlist.

Identity Cloud has no automatic mechanism to delete existing user sessions when a user changes their password. To implement automatic invalidation of existing sessions on password reset, consider one of the following approaches:

Make sure only authorized people can access Identity Cloud, and audit system access periodically.

The more features you have turned on, the greater the attack surface. If something is not being used, switch it off, or remove its configuration to deactivate it. These are some features to consider turning off:

Ensure you harden your password policy for each realm. These are some common ways to harden a password policy:

Refer to Password policy.

Account lockout is a security mechanism that locks a user account after repeated failed login attempts. You can use it to supplement your password policy to slow down brute-force attacks.

To learn more about how to configure account lockout and implement account lockout in your journeys, refer to Account lockout.

Ensure any automated scripts do not rely on a tenant administrator account to generate an access token. Instead, use a service account. Additionally, restrict the scopes that a service account can grant only to those needed by the automated script.

Refer to Service accounts.

Make sure 2-step verification is mandatory for tenant administrators.

Refer to Tenant administrator mandatory 2-step verification FAQ.

Different algorithms and methods are discovered and tested over time, and communities of experts decide which are the most secure for different uses. Use up-to-date cryptographic methods and algorithms to generate keys.

Small keys are easily compromised. Use at least the recommended key size.

Ensure sensitive data such as passwords and encryption keys are stored in ESV secrets, and never embedded directly in configuration or scripts.

Refer to the Secrets section of Introduction to ESVs.

These are some reasons to rotate keys regularly:

For more information, refer to Use ESVs for signing and encryption keys.

Identity Cloud supports encryption of data stored in the repository. Data can be encrypted using reversible encryption or one-way encryption.

ForgeRock recommends you encrypt all sensitive data. These are examples of sensitive data:

Refer to Secure identity data.

OpenID Connect 1.0 (OIDC) ID tokens can contain sensitive data and personally identifiable information (PII). ForgeRock recommends you encrypt all ID tokens.

Refer to Encrypt ID tokens and backchannel logout tokens.

Login journeys are vulnerable to brute force attacks. You can mitigate this risk by using the Identity Store Decision Node in your login journeys and implementing the Locked outcome in conjunction with account lockout.

Refer to Identity Store Decision node.

Registration journeys are vulnerable to denial-of-service attacks, where attackers try to create extremely high numbers of new users with the intention of exhausting system resources and creating an outage. You can mitigate this risk by using the Email Suspend node in your registration journeys to prevent new users from being created until an email address is verified.

Refer to Email Suspend node.

Identity Cloud is preconfigured with default journeys to get you started. However, ForgeRock recommends you harden these default journeys or implement your own journeys using security best practices; for example, by adding MFA to a login journey to confirm user identity using a device.

Once you have built your journeys, ensure you deactivate any unused journeys, particularly insecure login journeys that only require a username and password.

Refer to the Deactivate a journey section of Journeys.

If you have developed your own end-user journey and account experience using ForgeRock SDKs or APIs, ForgeRock recommends that you deactivate the hosted journey pages and/or the hosted account pages to ensure there is no risk of unauthorized access by a malicious user.

Refer to Identity Cloud hosted pages.

Misconfiguration can arise from bad or mistaken configuration decisions and poor change management. Depending on the configuration error, features can stop working in obvious or subtle ways and potentially introduce security vulnerabilities.

To guard against bad configuration decisions, implement good change management:

Despite efforts to improve how people manage passwords, users have more passwords than ever before, and many use weak passwords. You are strongly encouraged to use a password manager to generate secure passwords.

Identity Cloud provides an audit logging service that captures key auditing events critical for system security, troubleshooting, and regulatory compliance.

Audit logs gather operational information about events that occur within an Identity Cloud tenant. They track processes and security data, such as authentication mechanisms, system access, user and administrator activity, error messages, and configuration changes.

You are strongly encouraged to set up systems to monitor your audit logs and alert you to unusual patterns of behavior.

Refer to Monitor your tenant.