PingOne

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

Service interruptions during migration

The migration process involves copying all user, device, and configuration data from the legacy PingID account to your PingOne environment. During this process, the following operations are temporarily suspended until migration is complete:

  • 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: Only the default Fraud template is migrated to PingOne. If the Fraud template was customized in a PingID account, it is reset to the default template after migration.

  • 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 OSs 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 screen appears, 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. In PingOne SMS, Voice, and Email notifications are always localized to supported languages in PingOne. If a user’s browser is set to a language that is supported by PingOne that language is automatically applied.

  • Regional support:

    PingOne environments created in the Canada region 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, MFA status applied to user accounts in PingOne after migration is handled 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:

    The Mobile OS version rule isn’t supported in PingOne, and must be removed before migrating. The equivalent functionality can be configured directly in the PingID mobile application in the Applications page.

  • Location-based rules:

    The location-based part of the following rules isn’t supported in PingOne, and must be removed from the following rules 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’ll have the opportunity to 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.

  • Number matching:

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

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

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

IdP considerations

If PingFederate is the IdP

After integrating with PingOne, PingID accounts that were using 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.

After migration is complete, environments with PingFederate as their IdP should consider any post-migration changes that might be required for their environments.

For a list of common considerations, see Considerations after integrating or migrating a PingID account into a PingOne environment.

If using PingOne for Enterprise with PingOne directory as the IdP

When integrating PingID with PingOne, admin user accounts from the PingOne for Enterprise directory can’t be migrated to a PingOne environment.

After completing the integration process, administrators must manually create the equivalent administrative user accounts in the PingOne administrators environment and assign them the admin permissions necessary to manage the PingOne environment with which you integrated the PingID account.

When using PingOne directory as your IdP, if you want to change to a different IdP when migrating to PingOne, be aware that user account information from PingOne directory isn’t migrated, and would need to be recreated in the new IdP.

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

User directory changes

After migration, PingOne usernames are immutable and can’t be changed. This is because the username that appears in the PingOne directory is used by the PingID service to identify the user.

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 follows 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 rollback 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 rollback 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 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 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.