Access Management 7.3.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

  • Persistent cookie nodes (authentication trees)

    Requires a key pair alias for encryption. For more information, refer toSet 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, refer to Create a user self-service service instance.

  • Amster

    Requires an sms.transport.key key alias to export and import encrypted passwords.

    For more information, refer to 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, refer to Client-side session security.

  • Authentication trees

    Requires a key alias to encrypt values stored in the authentication tree’s secure state.

    For more information, refer to 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, refer to 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, refer to Sign and encrypt messages. For a list of the secret ID mappings, refer to Secret ID default mappings.

  • Persistent Cookie module (authentication chains)

    Requires a key pair alias for encryption.

    For more information, refer to 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, refer to 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, refer to 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, refer to 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, refer to 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, refer to Configure CSV audit event handlers.