AM features that use keys
Features that require secrets for signing or encryption can use one of the following mechanisms:
-
The AM keystore, configured at Configure > Server Defaults > Security > Key Store.
-
The secrets API (secret stores).
Certain features require secret stores, and some support either secret mechanism. This list outlines which features can use which secret mechanism:
- Features that only use the AM keystore
-
-
Persistent cookie nodes (authentication trees)
Requires a key pair alias for encryption. For more information, see Set Persistent Cookie node.
-
User self-service
Requires a JCEKS keystore with a key pair alias for encryption and a key alias for signing.
For more information, see Create a user self-service service instance.
-
Amster
Requires an
sms.transport.key
key alias to export and import encrypted passwords.For more information, see the Amster documentation.
-
IDM user self-registration
Requires copying signing and encryption keys from IDM into the AM keystore.
For more information, see Delegate user self-registration to IDM.
-
- Features that use secret stores
-
-
Client-side sessions
Require keys or secrets for signing and encrypting client-side sessions and authentication sessions.
For more information, see Client-side session security.
-
Authentication trees
Requires a key alias to encrypt values stored in the authentication tree’s secure state.
For more information, see Store values in a tree’s node states.
-
OAuth 2.0 providers
Require a key alias for signing client-side tokens and OpenID Connect ID tokens. Also require a key alias for encryption of client-side OAuth 2.0 access and refresh tokens.
For more information, see Configure client-side OAuth 2.0 token encryption.
-
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.
-
Remote Consent service
Requires a key alias for signing consent responses, and another key alias for encrypting consent responses.
For more information, see Remote consent.
-
SAML v2.0 federation
Requires key pairs for signing and encrypting messages, responses, and assertions; for example, a key to encrypt the JWT stored in the local storage of supported browsers.
You might also require a key to sign exported metadata.
For more information, see Sign and encrypt messages. For a list of the secret ID mappings, see Secret ID default mappings.
-
Persistent Cookie module (authentication chains)
Requires a key pair alias for encryption.
For more information, see Persistent Cookie module.
-
- Features that support different keystore configurations
-
-
ForgeRock Authenticator (OATH), ForgeRock Authenticator (PUSH) modules, and the WebAuthn Profile Encryption service
Support configuring a different keystore to encrypt device profiles. Also support keystore types that are not available to other features.
For more information, see 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 different bootstrap keystore, provided:
-
You keep the password strings updated.
-
You overwrite the
boot.json
file before AM starts up.
For more information, see Replace the AM keystore.
-
-
- Features that require different keystore configurations
-
-
Java fedlets
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.properties
file. For more information, see Configure Java fedlet properties. -
Security token service
Requires a JKS keystore for encrypting SAML v2.0 and OpenID Connect tokens. Does not require files to store the keystore password or the key aliases' passwords.
For more information, see Configure STS instances.
-
CSV audit logging handler
Requires a keystore for tamper-proofing. Does not require a file to store the keystore password; the password is configured in the AM admin UI. For more information, see Configure CSV audit event handlers.
-