Features in AM That Use Keys

User self-service

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".

Client-based sessions

Requires an key pair alias for encryption and a key pair alias for signing. For more information, see "Configuring Client-Based Session Security".

Persistent Cookie nodes (authentication trees)

Requires a key pair alias for encryption. For more information, see "Set Persistent Cookie Node".

Amster

Requires a sms.transport.key key 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".

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.

Authentication trees

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.

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:

For more information, see "To Replace the AM Keystore".

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 "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".