Features in AM That Use Keys
Most features that require storing secrets for signing or encryption use the AM keystore, which is configured by going to Configure > Server Defaults > Security > Key Store. However, some features may require or support different configurations:
- Features that only use the AM keystore
Requires a JCEKS keystore with a key pair alias for encryption and a key alias for signing. For more information, see "Creating a User Self-Service Service Instance".
Persistent Cookie nodes (authentication trees)
Requires a key pair alias for encryption. For more information, see "Set Persistent Cookie Node".
sms.transport.keykey alias to export and import encrypted passwords. For more information, see the Amster Command-line Interface Guide.
IDM user self-registration
Requires copying signing and encryption keys from the IDM installation into the AM keystore. For more information, see "To Delegate User Self-Registration to IDM".
- Features that use secret stores
Require keys or secrets for signing and encrypting client-based sessions and authentication sessions. For more information, see "Configuring Client-Based Session Security".
Web and Java agents
Web Agents and Java Agents communicate with AM using a built-in OAuth 2.0 provider configured globally in AM. This communication requires a key alias for signing tokens. For more information, see the ForgeRock Web Agents User Guide and the ForgeRock Java Agents User Guide.
OAuth 2.0 providers
Requires a key alias for signing client-based tokens and OpenID Connect ID tokens. For more information, see "Configuring Client-Based OAuth 2.0 Token Digital Signatures" and "Configuring ID Token Signatures".
Also requires a key alias for direct authentication encryption of client-based OAuth 2.0 access and refresh tokens. For more information on enabling encryption, see "Configuring Client-Based OAuth 2.0 Token Encryption".
Persistent cookie modules (authentication chains)
Requires a key pair alias for encryption. For more information, see "Persistent Cookie Module".
Remote Consent Service
Requires a key alias for signing consent responses, and another key alias for encrypting consent responses. For more information, see The Remote Consent Service.
Requires a key alias to encrypt values stored in the authentication tree's secure state. For more information, see "Storing Secret Values in Transient Tree State and the Secure State".
SAML v2.0 Federation
Requires key pairs for signing and encryption of messages, responses, and assertions; for example, a key to encrypt the JWT stored in the local storage of supported browsers.
You may also require a key to sign exported meta data.
For more information, see Signing and Encryption.
For a list of the secret ID mappings, see "Secret ID Default Mappings".
- Features that support different keystore configurations:
ForgeRock Authenticator (OATH), ForgeRock Authenticator (PUSH) modules, and the WebAuthn Profile Encryption Service
Supports configuring a different keystore to encrypt device profiles. They also support different keystore types that are not available to other features. For more information, see "About Multi-Factor Authentication".
AM's startup (bootstrap) process
Requires two password strings. ForgeRock recommends that you use the AM keystore as the bootstrap keystore, but you can configure a bootstrap keystore as long as:
You keep the password strings updated.
You overwrite the
boot.jsonfile before AM starts up.
For more information, see "To Replace the AM Keystore".
- Features that require different keystore configurations:
Require a keystore containing a key pair to sign and verify XML assertions and to encrypt and decrypt SAML assertions. Keystore and key information are configurable in the
FederationConfig.propertiesfile. For more information, see "Configuring Java Fedlet Properties".
Security Token Service
Requires configuring a JKS keystore for encrypting SAML v2.0 and OpenID Connect tokens. It does not require files to store the keystore password or the key aliases' passwords. For more information, see Configuring STS Instances.
CSV audit logging handler
Requires configuring a keystore for tamper-proofing. It does not require a file to store the keystore password; the password is configured in the AM console. For more information, see "Configuring CSV Audit Event Handlers".
If you are creating your own custom components or plugins, you can implement the
SecretIdProvider interface for exposing your own custom secrets.
For more information, see the AM 7.1.0 Public API Javadoc.