Secret label default mappings

The following table shows the secret label in which you can store the password used to decrypt password-encrypted PEM files.

Encode the password using the https://am.example.com:8443/am/encode.jsp page.

The following table shows the secret label mapping to use when encrypting client-side sessions:

⁽¹⁾ This secret label replaces the legacy Encryption Symmetric AES Key configuration property (under Configure > Global Services > Sessions > Advanced). If you set both the configuration property and the secret label mapping, the mapping takes precedence.

⁽²⁾ This secret label is deprecated and will be removed in a future release. Use the algorithm-specific secret labels in this table instead. These secret labels make it easier to configure and rotate secrets.

The following table shows the secret label mapping to use when signing client-side sessions:

⁽¹⁾ This secret label replaces the legacy Signing HMAC Shared Secret configuration property (under Configure > Global Services > Sessions > Advanced). If you set both the configuration property and the secret label mapping, the mapping takes precedence.

⁽²⁾ This secret label is deprecated and will be removed in a future release. Use the algorithm-specific secret labels in this table instead. These secret labels make it easier to migrate and rotate secrets. If you set this secret label and an algorithm-specific secret label, the algorithm-specific label takes precedence.

The secret label mapping to encrypt the certificate used to authenticate to the CRL cache server.

Learn more about CRL caching in Certificate revocation list caching.

The secret label mapping for the HTTP client proxy password used to authenticate HTTP outbound requests.

AM verifies the FIDO metadata blob signature against secrets mapped to this secret label.

This table shows the ID for the Google hardware attestation root certificate.

This certificate is used to confirm the keys used by bound Android devices are valid, have not been revoked, and use hardware-backed security storage.

Refer to Verifying hardware-backed key pairs with Key Attestation in the Android developer documentation.

The following table shows the secret label mappings used to encrypt and sign persistent cookies for the Set Persistent Cookie node and Persistent Cookie Decision node:

⁽¹⁾ The am.authentication.nodes.persistentcookie.encryption label overrides the value for Persistent Cookie Encryption Certificate Alias in the Core authentication attributes.

⁽²⁾ Map the am.authentication.nodes.persistentcookie.identifier.signing dynamic secret label to override the HMAC Signing Key node property, where identifier is the value of the HMAC Signing Key Secret Label Identifier.

The following table shows the secret label mapping used to encrypt sensitive data stored in the secure state of an authentication tree:

The secret label mappings for the HMAC secret used to sign and verify the authentication token (authID):

This mapping overrides the randomly-generated core authentication attribute, Organization Authentication Signing Secret.

You can map multiple secrets to this label to enable secret rotation. AM signs the authentication token with the active secret but checks all mapped secrets when verifying the authentication token signature. Therefore, if you rotate the active secret while an authentication request is in progress, the returned authentication token can still be verified.

If you delete the secret that was used to sign an authentication token, the authID returned in the authentication request can’t be verified and authentication fails.

The dynamic secret labels for authentication nodes, where identifier is defined in the node configuration:

The secret label mappings for services that use encrypted device storage.

These mappings override the encryption keys set in the service configuration.

The following table shows the secret label mappings for CA certificates used by the httpclient script binding to secure HTTP requests.

⁽¹⁾ Map the am.services.httpclient.mtls.clientcert.identifier.secret dynamic secret label to the certificate to be used by the httpclient script binding when making HTTP requests. The identifier is the value of the Client Certificate Secret Label Identifier set in the HTTP Client service configuration.

⁽²⁾ Map the am.services.httpclient.mtls.servertrustcerts.identifier.secret dynamic secret label to the truststore of certificates that verify the server certificate. The identifier is the value of the Server Trust Certificate Secret Label Identifier set in the HTTP Client service configuration.

The following table shows the secret label mappings used by the httpclient script binding to route HTTP requests through a proxy connection.

⁽¹⁾ Map the am.services.httpclient.proxy.identifier.secret dynamic secret label to the secret to be used by the httpclient script binding when making HTTP requests. The identifier is the value of the Proxy Secret Label Identifier set in the HTTP Client service configuration.

The following table shows the secret label mapping that the IoT service uses when configured as a trusted OAuth 2.0 JWT issuer:

The following table shows the secret label mapping for the CA certificate that the Register Thing node uses to verify the X.509 digital certificate included in the proof-of-possession JWT:

The secret label mappings to encrypt the certificate used to authenticate Policy Configuration service connections:

The secret label mapping for the Amazon Simple Notification Service access key used by the Push Notification service. The secret mapping overrides the SNS Access Key Secret set in the service configuration.

This table shows the secret label mapping used to encrypt the JWTs SAML 2.0 creates in session storage:

This table shows the secret label mappings used to sign SAML 2.0 metadata:

The following table shows the secret label mappings used to sign and encrypt SAML 2.0 elements, and to enable mTLS authentication between entity providers:

⁽¹⁾ This algorithm is for compatibility purposes only. Avoid its use.

⁽²⁾ For artifact resolution requests only, the SP uses the certificates mapped to this secret label for mTLS authentication to the remote IdP. These certificates are exported with <KeyDescriptor use="signing"> in the SP metadata.

⁽³⁾ The SP uses the certificate mapped to this secret label for basic authentication. If you set a Secret Label Identifier, and AM finds a mapping to am.applications.federation.entity.providers.saml2.identifier .basicauth, AM uses this secret and ignores the value of the Password field. For basic authentication, there is no default secret label for the realm, or globally.

You can specify a custom Secret Label Identifier for each SAML 2.0 entity provider in a realm. AM generates new secret labels that can be unique to the provider, or shared by multiple providers.

For example, you could add a custom secret label identifier named mySamlSecrets to a hosted identity provider. AM then dynamically creates the following secret labels, which the hosted identity provider uses for signing and encryption:

AM attempts to look up the secrets with the custom secret label identifier. If unsuccessful, AM looks up the secrets using the default secret labels.

The secret label mappings to encrypt UMA persisted claims tokens (PCTs):

The secret label mappings to encrypt and sign the user self-service snapshot token.

The following table shows the secret label mapping used sign the JWTs provided to web and Java agents: