Plan for security in Identity Cloud
When you set up your Identity Cloud tenant environments, you must ensure that they are configured with security in mind.
The following topics lay out a comprehensive list of actions to take to help you set up Identity Cloud as securely as possible. However, security is a very broad subject, and every Identity Cloud customer has different use cases; you are expected to do your own research to complement the information found in these topics.
You should also ensure any changes you make to security settings in Identity Cloud follow your own corporate security policies, especially in relation to password complexity and active features.
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,
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.
Configure cross-origin resource sharing (CORS) to securely share browser resources across domains.
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:
This header specifies which version of the REST API to use. Use this header in your requests to ensure future changes to the API do not affect your clients.
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:
Requests with a body size larger than 1 MiB (1,048,576 bytes).
Requests that contain JWTs that expand to a size larger than 32 KiB (32,768 bytes) when decrypted.
ForgeRock provides policy enforcement points (PEPs) to improve application security by enforcing Identity Cloud authentication and authorization decisions in your applications:
Use ForgeRock Identity Gateway to protect your applications without modifying them or the infrastructure where they run—whether on-premises, in a public cloud, or in a private cloud. Identity Gateway acts as a reverse proxy, intercepting client requests and server responses to enforce authentication and authorization.
Use ForgeRock web or Java policy agents to protect your applications when you have access to the infrastructure where they run. Policy agents natively plug into web or application servers and intercept inbound requests to enforce authentication and authorization. You can manage the policy agent configurations centrally from Identity Cloud.
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:
logoutByUseraction, specifying the username in the request payload.
This action can be used for server-side and client-side sessions and is described in Invalidate all sessions for a user.
Use a query to locate all sessions for a user, then use the
logoutByHandleaction to invalidate those sessions.
This action can be used for server-side sessions only and is described in Invalidate specific sessions.
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:
Require a minimum of 12 characters
Prevent the use of repetitive characters
Prevent the use of commonly used passwords
Prevent reuse of the last three passwords
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.
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.
These are some reasons to rotate keys regularly:
To limit the amount of data protected by a single key.
To reduce dependence on specific keys, making it easier to migrate to stronger algorithms.
To prepare for when a key becomes compromised. The first time you try key rotation, it shouldn’t be during a real-time recovery.
To conform to internal business compliance requirements.
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:
Credit card numbers
Government benefit ID numbers
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.
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.
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:
For all enabled features, document why they are enabled and what your configuration choices mean. This implies a review of configuration settings, including default settings that you accept.
Validate configuration decisions with thorough testing.
Maintain a record of your configurations and the changes applied.
Use version control software for any configuration scripts and to record changes to configuration files.
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.