What you need to know before integrating or migrating a PingID account into a PingOne environment
If you are integrating an existing PingID account into a PingOne environment, or migrating the management of your PingID account to PingOne read the following.
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, Modify end-user or administrator MFA devices.
-
User operations: Create, Delete, 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 does not include the service provider (SP) name.
PingID template PingOne template 
-
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 is expanded 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 would automatically fallback 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 do not include the
spAlias(the alias used to identify the authentication service). -
Web and RADIUS Gateway only:
If FIDO2, security key, or platform biometrics are configured as a user’s primary authenticating device, and Default to Primary is also selected, if the accessing device does not support WebAuthn the Device Selection window presents a list of the user’s paired devices, rather than falling back to the next authentication method in the list, as would otherwise be expected.
If you are using a RADIUS Gateway, you can solve this issue by performing additional configuration steps detailed in this Knowledgebase article.
-
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 cannot 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 did not exist. To overrride PingOne’s account validation, in the MFA policy, select the Skip user lock verification checkbox.
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 is not 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 is not 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.
API changes
The following PingID APIs are not supported when PingID is managed out of PingOne:
-
OATH token API
-
User Management API:
-
EditUser
-
DeleteUser
-
It is recommended to use PingOne APIs after integrating a PingID account into PingOne, however all other PingID APIs will continue to function and can still be used.
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 Adding attribute mapping for inbound provisioning. |
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 cannot 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 those accounts 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 is not migrated, and would need to be recreated in the new IdP. |
Learn more about PingOne administrator management in Managing administrators and Managing administrator roles.