--- title: Managing signature verification settings description: Under SAML 2.0 specifications, when your site receives any SAML 2.0 messages with the POST or Redirect bindings, the messages must be digitally signed. component: pingfederate version: 13.1 page_id: pingfederate:administrators_reference_guide:pf_managing_signature_verification_settings canonical_url: https://docs.pingidentity.com/pingfederate/13.1/administrators_reference_guide/pf_managing_signature_verification_settings.html llms_txt: https://docs.pingidentity.com/pingfederate/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: July 10, 2024 section_ids: about-this-task: About this task steps: Steps --- # Managing signature verification settings Under SAML 2.0 specifications, when your site receives any SAML 2.0 messages with the POST or Redirect bindings, the messages must be digitally signed. ## About this task Signing is also always required for the SAML 1.x POST binding and for WS-Federation assertions, as well as incoming SAML 1.1 or 2.0 tokens for WS-Trust STS processing. Depending on your agreement with this idenity provider (IdP), single sign-on (SSO) assertions, SAML 2.0 artifacts, or SOAP messages might also require signatures. ## Steps 1. On the **Signature Verification Settings** tab, click **Manage Signature Verification Settings**. 2. On the **Trust Model** tab, select a trust model on the **Certificate Verification Method** tab. * Anchored The partner certificate must be signed by a trusted certificate authority (CA). Optionally, you can also restrict the issuer to a specific Trusted CA to mitigate potential man-in-the-middle attacks and to provide a means to isolate certificates used by different connections. The CA's certificate must be imported into the PingFederate Trusted CA store in the **Security > Certificate & Key Management > \[.wintitle]** **Trusted CAs**\*\* window. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | If you are using the redirect binding for single logout (SLO) or establishing an OAuth assertion grant connection to exchange JSON web tokens (JWTs) for access tokens. you cannot use anchored certificates because SAML 2.0 does not permit certificates to be included using this transport method and the signature verification process for JWTs requires the public keys to validate the digital signatures. | * Unanchored The partner certificate is self-signed or you want to trust a specified certificate. | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | When anchored certificates are used between partners, certificates can be changed without sending the update to your partner. If the certificate is unanchored, any changes must be promulgated.For more information, see [Digital signing policy coordination](../introduction_to_pingfederate/pf_digi_sign_poli_coordin.html). | | Trust model | Subsequent steps | | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Anchored | On the **Subject DN** window:1) Enter the `Subject DN` of the certificate or extract it from your service provider (SP) partner's certificate if the certificate is stored on an accessible file system. 2) (Optional) Select the **Restrict Issuer** checkbox and enter the `Issuer DN` of the certificate. Alternatively, extract it from your partner's certificate. Consider enabling this option to mitigate potential man-in-the-middle attacks and to provide a means to isolate certificates used by different connections. | | Unanchored | On the **Signature Verification Certificate** window:1) Select a certificate from the list. If you have not yet imported the certificate from your partner, click **Manage Certificates** to do so. See [Managing certificates from partners](pf_managing_certificates_from_partners.html). 2) (Optional) Select additional certificates. When configured, PingFederate considers a digital signature valid so long as it can verify the signature using one of the certificates from this list. This is useful in situations where your partner has sent you a certificate to replace the current certificate. Adding this second certificate allows PingFederate to continue validating digital signatures as the partner switches to the new signing certificate. It also adds support for the scenario where your partner uses a pool for certificates to sign its messages. Adding these certificates ensures digital signatures can be validated as the partner rotates its signing certificates. | On the **Summary** tab, review your configuration and perform one of the following tasks. * Amend your configuration Click the corresponding tab title and then follow the configuration wizard to complete the task. * Keep your changes Click **Done** and continue with the rest of the configuration. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------ | | | When editing an existing configuration, you can also click **Save** as soon as the administrative console offers the opportunity to do so. | * Discard your changes Click **Cancel**.