Access Management 7.2.2

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

    Learn more in the Web Agents User Guide and the 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.