PingAM 8.0.0

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 journey and authenticated sessions.

    Learn more in Client-side session security.

  • Authentication trees

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

    Learn more in 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.

    Learn more in 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.

    Learn more in 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 could also require a key to sign exported metadata.

    Learn more in Sign and encrypt messages. You can find a list of the secret label mappings in Secret label default mappings.

  • Persistent cookie nodes

    Requires a key pair alias for encryption.

    Learn more in Set Persistent Cookie node.

Features that support different keystore configurations

  • ForgeRock Authenticator (OATH), ForgeRock Authenticator (PUSH), and the WebAuthn Profile Encryption services

    Support configuring a different keystore to encrypt device profiles. Also support keystore types that aren’t available to other features.

    Learn more in Multi-factor authentication.

  • AM’s startup (bootstrap) process

    Requires two password strings. Use the AM keystore as the bootstrap keystore where possible. If you configure a different bootstrap keystore, you must:

    • Keep the password strings updated.

    • Overwrite the boot.json file before AM starts up.

    Learn more in 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. Learn more in Configure Java fedlet properties.

  • Security token service

    Requires a JKS keystore for encrypting SAML v2.0 and OpenID Connect tokens. Doesn’t require files to store the keystore password or the key aliases' passwords.

    Learn more in Configure STS instances.

  • CSV audit logging handler

    Requires a keystore for tamper-proofing. Doesn’t require a file to store the keystore password; the password is configured in the AM admin UI. Learn more in Configure CSV audit event handlers.