Configuring a SAML Token Processor instance - PingFederate - 10.3

PingFederate Server

bundle
pingfederate-103
ft:publication_title
PingFederate Server
Product_Version_ce
PingFederate 10.3
category
Product
pf-103
pingfederate
ContentType_ce

The integrated SAML (1.1 or 2.0) Token Processor accepts and validates SAML (1.1 or 2.0) security tokens. The PingFederate security token service (STS) validates digital signatures using all trusted certificate authorities (CAs) imported into PingFederate.

On the Instance Configuration tab, configure a SAML Token Processor instance.

You can restrict the signature verification process by subject distinguished names (DN), issuers, or both to limit the token requests accepted for this token processor instance.

You must indicate a unique identifier for the PingFederate STS. Token processor instances reject SAML tokens that do not contain the identifier in the audience element.

  • Go to Authentication > Token Exchange > Token Processors.
  • On the Instance Configuration tab, configure the basics of the token processor instance.
    1. In the Audience row, in the field value field, enter the URI that uniquely identifies your federation gateway for this SAML protocol.
      This is the federation ID for the STS for either SAML 1.1 or SAML 2.0 tokens, depending on which processor you are configuring.
    2. Optional: Click Add a new row to 'Valid Certificate Issuer DNs' to enter one or more issuers.
      Important:

      If issuer DNs are specified here, then only those issuers are considered valid for verifying incoming digital signatures. Otherwise, all trusted certificate authorities (CAs) are used to verify signatures.

    3. Optional: Click Add a new row to 'Valid Certificate Subject DNs' to enter one or more subject DNs.
      Important:

      If subject DNs are specified here, then only those subject DNs are considered valid for verifying incoming digital signatures. Otherwise, all trusted certificate authorities (CAs) are used to verify signatures.

      If you specify both issuer DNs and subject DNs, then the certificate used to validate signatures must match an entry in both lists.

      If you provide no issuer DN and subject DN, then all certificates are treated as valid for purposes of verification.