Just-in-Time Migration

Next Identity Adopt's Just-in-Time migration feature takes an incremental approach to data migration. Instead of completing the entire migration in a short time frame, Just-in-Time migration runs the old and new systems in parallel, migrating data as users authenticate. This can be achieved by allowing the home IDP to interact with the local IDP through an API or by providing a managed interface for connecting to the home IDP.

JIT migration also adds a flag in the user record to indicate the home IDP of the consumer. One of the benefits of JIT migration is that the home IDP password hash doesn't need to be supported since the user's password can be validated with the home IDP and stored in the local IDP using the native hash. JIT migration accounts for various scenarios, including users who have already been migrated and exist in a second home IDP, as well as merging flows for users who already exist in the local IDP.

JIT migration is initiated for clients with enabled JIT migration and a configured home IDP. It now checks for the presence or absence of the correct external system ID, rather than just any external system ID.

Just-in-Time Migration Terminology

• Local IDP: Next Identity IDP
• Home IDP: External IDP (e.g., third-party IDP like Salesforce or a homegrown IDP)
• externalSystemsMapping: An object in the NI record that stores the home user ID and IDP information, marking the user as migrated.

Just-in-Time Migration Overview

Here's the workflow for just-in-time migration:

1. The end user visits the website or app and is prompted to sign in using their home IDP credentials.
2. The end user's credentials are used to check if the record exists and matches in both the home IDP and local IDP.
3. Based on the results of the checks, either a new user record will be created in the local IDP, or an existing record in the local IDP will be updated.

When a record exists in both the local IDP and the home IDP, a check is performed to see if the key user attributes are the same or different. The user may be prompted to choose a "primary" set of data to be written into the local IDP, which is known as a merge workflow. The details of both the Journeys and API flows are provided below.

Note: The JITm feature is only available for clients with email and password login.

External ID Providers Storage

The external systems mapping object is used to determine whether the user has been migrated, indicate the source of the migration, and store the user's external UUID. This object can store multiple external system IDs, allowing for tracking of users across different systems. Additionally, the migration type is stored in the external system mapping. This type can be 'Migrated', 'Updated', or 'Sustained'. Analyzing and understanding the events that occurred during the migration process is crucial.

Example

   "external_systems_mapping": {
        "app1_cognito": { //unique id of source
            "name": "App 1", //human friendly name ID source? 
            "user_id": "b12889c5-1080-641f-db98-6e6304a704e1", //user's external ID
            "created": "[TIMESTAMP]"
        }
    },

The key ID field is a unique identifier of the external IDP. It is a human-readable unique ID, and uniqueness is important when multiple external IDPs are on the same platform. The suggested format is as follows:

appname_idpname

Example:

loyaltybrand_cognito

someapp_salesforce

newssource_cognito (this is a different Cognito than the first example)

Migration Directions

The migration can occur in either direction. An external provider (system) can utilize the JIT API to facilitate migrating from the home IDP to the local IDP. Conversely, Next Identity supports integrations with external providers to seamlessly migrate consumers with just a few simple configurations.

Supported Home IDP Systems

As of the current implementation, our system can connect with Cognito and Keycloak IDP systems when used as Home IDP. However, we can create new connectors for other IDPs if required.

To be considered as a possible addition to the supported IDP list, at a minimum, a new IDP must:

• Support OIDC (OpenID Connect)
• Use email as the primary ID
• Offer authorization based on email and password

Supported External Identity Providers

Next Identity supports the following external identity providers: Amazon Cognito, Keycloak, and Salesforce Community Cloud.

External Systems API

Users who are logging into a new application and have not granted access will be prompted to accept. Once the consumer is authenticated, the application needs to be able to map the user to an external system ID. This mapping may happen automatically based on whether the client has JIT configured. If the client doesn't have JIT configured, the app needs a way to set this value manually. Therefore, an endpoint is required to update the externalSystemsMapping array in the NI user record.

• The API accepts a bearer token (from token delegation).
• The API provides GET, POST, and DELETE functions to retrieve the list of external IDs, create a new one, and delete one.
• The API can only access the external system(s) that the client has access to. This is handled by checking the client setting to get the external system ID and then checking the user record, allowing access only to that specific entry.
• If a POST is called and the system ID already exists, the API responds with a failure to update a duplicate entry message. This should be clearly logged for future reference if needed.

For more information, refer to the External System API reference.