PingOne

What you need to know before integrating or migrating a PingID account into a PingOne environment

If you’re integrating an existing PingID account into a PingOne environment, or migrating the management of your PingID account to PingOne read the following.

Don’t delete or modify the primary PingID administrator account used for the integration. Changing this account’s attributes can cause SSO failures and might prevent administrators from signing on.

Service interruptions during migration

The migration process involves copying all user, device, and configuration data from the legacy PingID account to your PingOne environment. The migration process temporarily suspends the following operations:

  • Multi-factor authentication (MFA) device management operations: Pair, Delete, or Modify end-user or administrator MFA devices.

  • User operations: Create, Delete, or Update.

  • All configuration changes within the legacy PingID admin portal and all configuration changes related to MFA in PingOne.

During migration end-users can continue to authenticate with devices that are already paired with their account.

End-user experience changes

  • Email notification templates:

    • Device Registration notification templates:

      • All templates relating to device registration and device authentication are automatically migrated to PingOne.

      • PingID custom templates for New Device Registration are automatically migrated to PingOne.

    • Strong authentication notification templates: When sending emails based on the strong authentication notification template, PingOne doesn’t include the service provider (SP) name.

      PingID template PingOne template

      Example of a PingID template, showing the SP name

      Example of a strong authentication template. The SP isn’t shown.

    • Report Fraud notification templates: The migration process resets custom Fraud templates to the default. The default Fraud template is renamed to New Device Paired in PingOne.

  • Device biometrics:

    As part of the migration process, the legacy PingID email notification template variable ${one-time-passcode} is automatically updated to ${\otp} in the equivalent PingOne email notification template.

    In PingOne, device biometrics is always enabled for both iOS and Android devices. For PingID accounts where device biometrics is set to Enabled or Required for only one OS (iOS or Android), the configuration expands to include both after PingID is integrated with PingOne.

  • Device fallback behavior:

    • SMS quotas: If a user exceeds the configured SMS quota and SMS is their default authentication method, PingID automatically falls back to the next authentication method on their list. In PingOne, the next time they attempt to authenticate, the Device Selection page displays, allowing them to choose a different authentication method.

  • Push notifications:

    In PingOne environments, push notifications to mobile devices don’t include the spAlias (the alias used to identify the authentication service).

  • Locale configuration changes for SMS, voice, and email notifications:

    In the PingID admin portal, you could disable localizations. PingOne always localizes SMS, Voice, and Email notifications. If a user’s browser is set to a language that’s supported by PingOne, that language is automatically applied.

  • Geographical support:

    PingOne environments created in the Canada geography can’t support Strong Authentication for Workforce use cases (PingID service).

  • MFA policy user account validation check:

    During authentication PingOne validates whether the user account is active. If the account is locked, the user is blocked from authenticating. In PingID this validation process didn’t exist. To override PingOne’s account validation, in the MFA policy, select the Skip user lock verification checkbox.

MFA status for user accounts when integrating an existing PingID account into an existing PingOne environment

When integrating an existing PingID account into an existing PingOne environment, PingOne handles MFA status for user accounts as follows:

  • For user accounts that existed in PingID only: The MFA status from the legacy PingID user account is carried over to the new user account in PingOne.

  • For user accounts that existed in PingOne only: The MFA status is automatically updated to Enabled after migration is complete.

  • For user accounts that existed in both PingID and PingOne: The MFA status is automatically set to Enabled when migrated to PingOne, unless the status in PingID was Suspended.

These changes apply when

Learn more about Configuring MFA settings.

Policy changes

There are several changes to the support of PingID policy rules when PingID is managed out of PingOne:

  • Mobile OS version:

    PingOne doesn’t support the Mobile OS version rule. You must remove it before migrating. The equivalent functionality can be configured directly in the PingID mobile application on the Applications page.

  • Location-based rules:

    The location-based part of the following rules isn’t supported in PingOne and must be removed before migrating a PingID tenant to PingOne:

    • Access from the company network rule

    • Recently authenticating from office rule

    • Recent authentication from company network

  • Limit push notifications rule:

    The Limit push notification rule is replaced by an equivalent configuration in the MFA policy. If your PingID account uses this rule, you can select the relevant MFA policy configuration during migration. Learn more about the Limit push notification configurations in PingOne in Configuring an MFA policy for strong authentication.

  • Default SMS and voice location deny list:

    A location deny list blocks notifications (SMS and voice) from being sent to specified countries. You can configure this in your Notification Policies.

    How PingOne configures the default deny list for notifications depends on your PingID integration type:

    • When migrating an existing PingID account: PingOne doesn’t set a deny list on the default notification policy. This is a safeguard to avoid blocking existing users who have access.

    • When creating a new PingID account in PingOne: The PingOne default notification policy is created with the Target Locations option enabled and a predefined list of countries selected.

    • When migrating to an existing PingOne environment: If the PingOne environment’s default notification policy already has a defined allow or deny list, the migration process resets it. You must reconfigure the default policy’s settings after migration.

    Learn more in Notification Policies.

  • Number matching:

    In PingOne environments, number matching is configured in the MFA policy. Learn more in Configuring an MFA policy for strong authentication.

  • Backup device:

    After migration, if a backup method was previously enabled for backup but not authentication in PingID, it will be enabled for authentication in PingOne, but with the Allow Pairing option disabled.

You can find information on recreating PingID policy rules using PingOne Protect predictors in Using predictors to recreate legacy PingID policy rules.

API changes

  • The following actions can’t be performed with the PingID API when PingID is managed out of PingOne:

    • OATH token operations

    • User Management:

      • EditUser

      • DeleteUser

    For these actions, you must use the PingOne API. You can find information on getting started with the PingOne API in Moving from the PingID API to the PingOne API

  • If your existing code uses the authonline endpoint from the PingID API in authentication flows, you could encounter problems after moving to PingOne. Replace these calls with code that uses the asynchronous mechanism provided in the PingID API, based on the startauthentication and authstatus endpoints.

IdP considerations

If PingFederate is the IdP

After integrating with PingOne, PingID accounts that used the PingID provisioner must use the PingOne provisioner for user provisioning.

When using PingOne provisioning, make sure MFA Device Management is set to Do not manage. Learn more in Creating an inbound rule.

If you use PingFederate as your IdP, you might need to make additional changes after migration.

You can find a list of common considerations in Considerations after integrating or migrating a PingID account into a PingOne environment.

If using PingOne for Enterprise with PingOne directory as the IdP

PingID tenants that use the built-in PingOne for Enterprise directory as their IdP must change the IdP before migration. The built-in PingOne for Enterprise directory is distinct from the PingOne directory, and isn’t supported for migration.

Learn more about PingOne administrator management in Managing administrators and Managing administrator roles.

User directory changes

After migration, PingOne usernames can’t be changed as they are used by the PingID service to identify users.

Verifying migration and handling user failures

The migration process is considered successful even if a small percentage of users, about 0.01%, fail.

  • Always check the PingID Admin Activity Report for any user errors after migration and specific users that failed.

    A screen capture of the Admin Activity Report migration message noting the migration was successful but 500 users were migrated with errors.

    In cases where the Admin Activity Report shows user errors, it also provides a list of the specific users that failed. You can use this information to remediate failed users.

    A screen capture of the Admin Activity Report with a failed user.

    Learn more about the Admin Activity Report in Running the PingID Admin Activity Report in the PingID Administrator Guide.

  • Remediating failed users:

    To remediate users who weren’t migrated, perform the following steps:

    1. Delete the users from the legacy PingID environment.

      To remove the user from the legacy PingID environment by API, contact your Ping Identity support representative for assistance.

    2. Recreate your user accounts in PingOne.

      Learn more about how to create PingOne users manually in Adding a user. Learn more about PingOne user API operations in Users in the PingOne API documentation.

Rollback options

The ability to rollback after completing the migration process varies according to the use case:

  • When Migrating PingID management from the legacy PingID admin portal to a PingOne environment:

    • If migration fails: Rollback of the PingID account happens automatically.

      A 24-hour cooldown period follows a rollback. Don’t attempt another migration during this time. Before retrying migration, contact Ping Identity support, as unresolved product issues can cause repeated failures.

    • If migration succeeds: To roll back your PingID account to a standalone account, you must delete your PingOne environment within 14 days of the successful migration. Any configurations made in PingOne during the period from successful migration to rollback are lost.

  • When Integrating a PingID account with a new PingOne environment:

    • If integration succeeds: To roll back your PingID account to a standalone account, you must delete your PingOne environment within 14 days of the successful integration. Any configurations made in PingOne during the period from successful integration to rollback are lost.

  • When Integrating an existing PingID account with an existing PingOne environment:

    • If integration fails: Rollback of the PingID account happens automatically.

      A 24-hour cooldown period follows a rollback. Don’t attempt another migration during this time. Before retrying migration, contact Ping Identity support. Unresolved product issues can cause repeated failures.

  • If integration succeeds: If the PingOne environment includes other services such as PingOne Protect, it might not be possible to delete it. Therefore, rollback to the standalone PingID account might not be possible. For further advice, contact your Ping Identity support representative.

Thresholding

A migration is considered successful with a migration failure rate of 0.01%, even if a very small percentage of users fail to migrate (approximately 0.01% of total users).