PingID SDK Provisioner

Known issues and limitations

Known issues

There are no known issues.

Known limitations

  • Due to a limitation with PingFederate 8.1 and earlier versions, when configuring two SP connections with the same provisioner, the second connection built may be pre-populated with the channel from the first connection. To avoid conflicts, delete this pre-populated channel and create a unique channel for each connection.

  • When an LDAP user is deleted in a targeted group distinguished name (DN), the provisioning connector does not propagate the deletion until a new user is added to the group. This limitation is compounded when the User Create provisioning option is disabled. For solutions, see SaaS provisioner does not remove the user in the Knowledge Base.

  • Due to PingFederate limitations, user attributes cannot be cleared once set.

  • Provisioning options may interact to produce undesired results if configured against recommendations. For example, we recommend that Provision Disabled Users be set to false when Remove User Action is Delete. If it is set to true, the following can occur:

    • A user exists in an active state in the user store and in PingID SDK. The user is disabled in the user store, so the provisioner deletes it from PingID SDK. An attribute of the user is updated in the user store. The provisioner will then re-create the user in PingID SDK in a disabled state.

  • The PingID SDK Connector manages all mapped email, SMS, and voice pairings. A device nickname of Email 1 and an attribute name of email1 are considered a pair. If the connector finds a device nickname (not attribute name) of email1 (created by a previous version of the connector) and a device nickname of Email 1, the latter takes priority and the former is removed.

  • If the selected Primary Authentication Method Upon Creation has no mapped attribute value or an invalid value, the primary device pairing will be set to the next available mapped attribute value. The order is Email (1, 2, 3), SMS (1, 2, 3), Voice (1, 2, 3).

Assigning a user to multiple applications

  • When managing multiple PingID SDK Applications, it is possible for a user to have a different active status in each application due to device pairings.

  • The PingID SDK create and suspend endpoints are global across all applications managed by your admin account. This means that if a user’s status changes in one application, the same action will be taken on all applications managed by your admin account.

    • If you create a user in one application with a device to pair, the user will be created in an active state in that application and a not_active state in other applications.

    • If there are two applications, each of which has an SP connection set up for it. In one SP connection, the Remove User Action is set to Disable and in the other it is set to Delete. A user in the directory has been targeted by both connections and as such, that user exists in both applications. The user is then disabled in the directory. Provisioner logs will show a delete and a create. The user will end up in a suspended state in both applications.

    • If there are two applications, each of which has an SP connection set up for it. In one SP connection, the Remove User Action is set to Disable and in the other it is set to Delete. Create a user in application A with an email or other device to pair. Create a user with the same username in the directory without the email or device. The user will then exist in an active state in application A and a not_active state in application B. Disable the user in the directory. The user will then be suspended in both applications. Enable the user in the directory. The user will then be not_active in both applications.