1. Click Identity Provider > Adapters to open the Manage IdP Adapter Instances screen.
  2. On the Manage IdP Adapter Instances screen, click Create New Instance to start the Create Adapter Instance configuration wizard.
  3. On the Type screen, configure the basics of this adapter instance.
    1. Enter the required information and select the adapter type from the list.
    2. Optional: Select a Parent Instance from the list.
      This is useful when you are creating an instance that is similar to an existing instance. The child instance inherits the configuration of its parent. In addition, you have the option to override one or more settings during the rest of the setup. Select the Override ... check box and make the adjustments as needed in one or more subsequent screens.
  4. On the IdP Adapter screen, configure your Composite Adapter instance as follows:
    1. Click Add a new row to 'Adapters'.
    2. Select an IdP adapter instance from the Adapter Instance list, configure the selected adapter instance and then click Update.

      Refer to the on-screen field descriptions and the following table for more information.

      Column Description
      Policy

      (Required)

      		 Required (the default) indicates authentication via this adapter instance is needed to continue SSO processing and to invoke any remaining instances in the chain. If you are integrating multifactor authentication, use this policy for each instance. The Composite Adapter instance returns an error when the authenticate attempt against a required adapter instance fails.

      Sufficient indicates that authentication via this adapter instance is enough to satisfy requirements (along with any required instances that have already been selected). Any subsequent configured instances in the chain are not invoked.

      Important:

      For the sufficient policy to work correctly, the adapter must return control to PingFederate after any kind of a failure.

      AuthN Context Weight

      (Required)

      		 If more than one adapter instance in the chain is capable of returning an authentication context, this relative weight is used to determine which value is included in the assertion, unless the value is overridden under AuthN Context Override.

      If weights are the same for two or more contexts, the first one processed is included in the assertion.

      The default value is 3.
      AuthN Context Override If provided, this value overrides the authentication context value that may be returned from the adapter instance. The value in this field may be sent in the assertion if the associated adapter instance is invoked.

      If weights are the same for two or more contexts, the first one processed is included in the assertion.
    3. Add at least one more adapter instance and configure its Policy, AuthN Context Weight, and AuthN Context Override settings.

      Repeat this step to add more adapter instances as needed.

      At runtime adapter chaining is sequential, starting at the top of the list.
      Important:

      Several types of adapters—for example, the IWA IdP Adapter—may be configured to direct end users to an error page if authentication fails for any reason, which will halt further progress through a composite-adapter chain. Ensure that for such adapter instances the Error URL option is not used in the instance configuration, if continuation through an adapter-chaining sequence is required.

    4. Optional: Use the workflow under Action to manage the selected adapter instances.
    5. Configure Input User ID Mapping.
      If you have configured any IdP Adapter developed using the IdpAuthenticationAdapterV2 interface from the PingFederate SDK (including the HTML Form Adapter), the Input User ID Mapping section appears. Additionally, some IdP adapters, such as the PingID™ Adapter and the separately available Symantec VIP Adapter, require a user ID to be passed in from an earlier-authentication step to perform multifactor authentication. If so, an administrator must specify the attribute containing the unique ID on this screen. For example, to pre-populate the username of an HTML Form Adapter instance with an attribute from an earlier authentication source in the previous steps:
      1. Click Add a new row to 'Input User ID Mapping'.
      2. Select the HTML Form Adapter instance from the Target Adapter list.
      3. Select a source attribute from the User ID Selection list.
      4. Click Update.
      Note:

      For OAuth use cases, entries in the Input User ID Mapping section could override the login_hint parameter value provided by the OAuth clients when they submit their requests to the /as/authorization.oauth2 authorization endpoint.

      Tip:

      By default, the HTML Form Adapter does not allow the users to change the username if it is configured to be pre-populated with an attribute from another authentication source. You can override this restriction by enabling the Allow Username Edit option on a per-adapter instance.

    6. Configure Attribute Name Synonyms.

      If any attributes are logically equivalent across two adapter instances but have different names, click Add a new row to 'Attribute Name Synonyms' and select attributes from the Name and Synonym lists to create a mapping between them.

      The attribute name under Synonym and its value are used in the SAML assertion, when the two values returned from each adapter are identical. If returned values are different, both values are sent for the synonym.

      Note:

      Without this configuration to identify synonymous attribute names, both names and their values are sent in the SAML assertion.

    7. Defines the order in which different values are returned for the same attribute name.

      For attributes of the same name configured in different adapter instances, you can change the order of returned values when the values are different. (Values are merged if they are the same.)

      By default (Add to Back) the value for an attribute name configured in the first instance is returned first and also listed first in the resulting SAML assertion. Then any different value from the same attribute name in a subsequently invoked instance is appended.

      The order might not matter for many attributes, but in the case of the SAML-subject attribute, only the first value in the SAML assertion may be used for an SP connection partner under normal circumstances. Click Add to Front to reverse the default order, if needed.

  5. On the Extended Contract screen, Add attributes to be returned from each adapter instance configured on the previous screen.
    Note:

    Attributes must correspond exactly to any or all of the attribute names listed on the Adapter Attribute screens for each configured adapter instance.

  6. On the Adapter Attributes screen, configure the pseudonym and masking options.
    Note:

    The Override Attributes check box in this screen reflects the status of the override option in the Extended Contract screen.

    1. Select the check box under Pseudonym for the user identifier of the adapter and optionally for the other attributes, if available.
      This selection is used if any of your SP partners use pseudonyms for account linking.
      Note:

      A selection is required regardless of whether you use pseudonyms for account linking. This allows account linking to be used later without having to delete and reconfigure the adapter. Ensure that you choose at least one attribute that is unique for each user (for example, email) to prevent the same pseudonym from being assigned to multiple users.

    2. Select the check box under Mask Log Values for any attributes that you want PingFederate to mask their values in its logs at runtime.
    3. Select the Mask all OGNL-expression generated log values check box, if OGNL expressions might be used to map derived values into outgoing assertions and you want those values masked
  7. Optional: On the Adapter Contract Mapping screen, configure the adapter contract for this instance with the following optional workflows:
    • Configure one or more data sources for datastore queries.
    • Fulfill adapter contract with values from the adapter (the default), datastore queries (if configured), context of the request, text, or expressions (if enabled).
    • Set up the Token Authorization framework to validate one or more criteria prior to the issuance of the adapter contract.
  8. On the Summary screen, review your configuration, modify as needed, and click Done to exit the Create Adapter Instance workflow.
  9. On the Manage IdP Adapter Instances screen, click Save to retain the configuration of the adapter instance.
    If you want to exit without saving the configuration, click Cancel.