Streamlining Customer Experience with SAP Customer Data Cloud: Leveraging Identity Sync for Seamless Migration

In this article, we delve into the captivating world of SAP CDC, explore the integration potential of Identity Sync Dataflow, and discover how it can revolutionize customer experience through a compelling use case.

In the ever-changing landscape of customer experience, businesses seek innovative solutions to create meaningful interactions with their customers. SAP Customer Data Cloud (CDC) emerges as a powerful ally, empowering enterprises to elevate their customer engagement strategies.

One of key features that facilitates this transformative journey is Dataflow (Identity Sync) , a magical tool that ensures a seamless migration process and enables customers to log in effortlessly with their existing credentials.

Migrating to SAP Customer Data Cloud: Empowering Password Hashing Algorithms

One critical aspect of migration is to ensure that users can log in effortlessly with their existing credentials after go-live . This use case revolves around migrating legacy password hashes to SAP Customer Data Cloud. As businesses embrace SAP CDC’s secure environment, they must transition their users’ passwords while preserving their security.

Gaining insights into how SAP Customer Data Cloud manages users’ legacy passwords and hash information.

To gain a comprehensive understanding, it is important to note that the hashing algorithm information is not centrally stored as a global setting or at the repository level. Instead, it is associated with each user, residing alongside their hashed password.
This approach liberates the system from any theoretical constraints, allowing the migration of multiple hashing algorithms into a single user repository. This becomes particularly advantageous during multi-source data migration, accommodating diverse systems with varying hashing algorithms.

Let’s examine the password object in its simplest form:

[abap]
{
"hashedPassword": "o8CKlJwknitT6dobp7avjZjKTK8=",
"hashSettings":
{
"algorithm": "pbkdf2_sha512",
"salt": "Y2YzYjZjOWY2OGIyMjUwZWNhNjU0MWNlN2JjZWNkYzA3MG NiMDI2YzBiODU2MjUyMTRhYzViOGU1NzgxYTVlMQ==",
"rounds": 10000
}
}
[/abap]

Within this object, the hashed version of the clear text password is provided, accompanied by the hash settings, specifying the algorithm used to generate the hash. In this instance, a straightforward pbkdf2_sha512 hash of “Test@12” is applied.

SAP Customer Data Platform boasts native support for a wide array of hashes, including “md5,” “sha1,” “sha1_hashbytes,” “sha256,” “sha512,” “sha512Hexa,” “md5_double_salted,” “md5_crypt,” “bcrypt, ” “pbkdf2,” “pbkdf2_sha256,” “drupal,” and “symphony2.”
This inclusive support allows for multiple variations based on hashing rounds, salt, and salt placement, with detailed documentation provided for the “password” parameter within the accounts.importFullAccount API.

Delve into the First Login and Re-Hash Process

When it comes to the login process, it is crucial to understand that SAP Customer Data Cloud requires the legacy hashing algorithm only once.
This occurs during the first login of a migrated user. Once the hash is validated, SAP Customer Data Cloud promptly re-hashes the password using its algorithm of the day, which is “pbkdf2” with specific hashing round settings.

The following diagram meticulously outlines the step-by-step process that takes place during this initial login.

How we can make use of Identity Sync-Dataflow to import the Password Hash into SAP CDC during Migration

How Identity Sync Dataflow Works:

Identity Sync enables you to read data from various platforms such as storage, marketing, or data management solutions, as well as from the CDC database. You can then transform this data in multiple ways and upload it to the target platform, which can be either CDC or a third-party platform. It serves as the go-to tool for integrating user data into third-party systems, facilitating migration between different CDC sites, and importing user data into CDC.

Key Components and Terminologies:

• Dataflow: Each Identity Sync job runs a dataflow, which consists of dedicated components for performing specific data integration operations.
• Components: The building blocks of the dataflow, including readers, writers, transformers, deleters, and look-ups, handle individual tasks in data processing.
• Reader: Extracts accounts from SAP Customer Data Cloud based on specific parameters.
• Writer: Uploads data to FTP, writes directly to a target platform, or sends it to a generic API endpoint.
• Transformer: Changes field names, creates a CSV file, and performs various custom data transformations.
• Import: Parses the file for Customer Data Cloud service to read it as JSON, injecting a job ID to each record for error handling.

Let’s explore the steps involved in the Dataflow process to import of passwords hashed with any algorithm.

Step 1 : Start the data migration process by loading a file containing user details, along with their respective password hashes.
Sample JSON Payload:

[abap]
{
"email": "sapcdc@test.com",
"hash": "o8CKlJwknitT6dobp7avjZjKTK8=",
"salt": "Y2YzYjZjOWY2OGIyMjUwZWNhNjU0MWNlN2JjZWNkYzA3MGNiMDI2YzBiODU2MjUyMTRhYzViOGU 1NzgxYTVlMQ=="
}
[/abap]

Step 2 : Parse the received JSON data ( it can also be CSV file , in that case csv parser is used ) to extract the necessary information for further processing.

Step 3 : Check if the user with email address already exists in SAP CDC by performing a lookup. If the user is present, retrieve their respective unique identifier (UID).

Step 4 : Rename the keys in the received JSON data to match the format accepted by SAP CDC for seamless integration.

Step 5 : Add any additional parameters(fields) required while importing the password hash into SAP CDC.

Step 6 : you can use a JavaScript code to convert the hash and password into a format compatible with SAP CDC, with help of script you can customize the incoming payload as per the requirement.

Step 7 : Proceed with the import of Gigya accounts by making an upsert call to SAP CDC.

The JSON payload for upsert looks like below:

[abap]
{
"UID": "unique identifier",
"profile": {
"email": "sapcdc@test.com"
},
"password": {
"hashSettings": {
"salt": "YjliZTI3OWQ2M2YyMjY1YTUyODAyODRkYTQzNTllNTJiM2UyMjhmMzg3MjkwZThiMWFlMTg1ZTgzNGVmNzI4MA==",
"rounds": "10000",
"algorithm": "pbkdf2_sha512"
},
"hashedPassword": "o8CKlJwknitT6dobp7avjZjKTK8="
},
"importPolicy": "upsert",
"loginIDs": {
"emails": [
"sapcdc@test.com"
]
}
}
[/abap]

Step 8 : Implement error handling mechanisms to deal with any potential errors during the data migration process. If an error occurs for any record, store the error message in a designated SFTP folder for further analysis and resolution.

Performing all above steps you can simply make use of dataflow to import the users and their password details from any external systems into SAP CDC during Migration process.

More info on Dataflows (Identity Sync) can be referred here.

Validation Process for Password Hashing Algorithm

Now that we’ve explored how to utilize Dataflow for importing password details, it’s time to make sure that everything functions as intended

The simplest and fastest way to validate that SAP Customer Data Cloud supports your password hashing algorithm is to import a few test users for whom you have both the hashed password and it’s clear text equivalent, then attempt a login with them.

To make things easier, I’ve included a Postman collection in this article. It contains all the necessary API calls for conducting this validation. This collection enables you to promptly test whether the hashed password from your existing database will function correctly after being imported into SAP Customer Data Cloud.

You have a few variables you’ll need to set in this collection in order for the calls to work

• DC – Data Center. This can be either one of the following values ​​depending on which data center your API Key is hosted:
  • us1.gigya.com – For the US data center.
  • eu1.gigya.com – For the European data center.
  • au1.gigya.com – For the Australian data center.
  • ru1.gigya.com – For the Russian data center.
  • cn1.gigya-api.cn – For the Chinese data center
• apiKey – Your SAP Customer Data Cloud API Key which can be found in the SAP Customer Data Cloud Console
• application Key & applicationSecret – The credentials used for API calls. We’re using a secret for simplicity sake rather than the best practice asymmetric key. More info on getting your application credentials here .

The API calls used are:

• accounts.importFullAccount : This method imports user account data into the Accounts Storage, including the password object
• accounts.login : This method logs a user into a site. This is used to validate that the clear text and the stored hash match.
• accounts.search : This method searches and retrieves data from the Accounts Storage using an SQL-like query. You can use it in this context to validate the data has been imported correctly and to compare the account before and after first login to witness the password re-hashing.
• accounts.deleteAccount : This method deletes the specified user’s account from the database. Used for quick cleanup of test data.

Validation process using Postman

Step 1 : To ensure the verification of the password hashing procedure, you can generate the password hash using JavaScript. Specifically, I am utilizing the crypto.pbkdf2Sync(password, salt, 10000, 512, 'sha512').toString('hex') hashing method within this particular context.

Step 2 :Use the hashed password and salt you created earlier to update the password details for the user in SAP CDC. Follow the setup shown in the screenshot, and don’t forget to include the needed information. Since you’re updating an existing user, remember to use the ‘importPolicy’ parameter set to ‘upsert’.

Step 3 : After importing the password details, you can confirm in SAP CDC whether the user’s password was updated accurately. To do this, execute an identity query : SELECT * FROM accounts WHERE profile.email=’ruchita.vanjari@acorel.nl’

Step 4 : Verify whether the user can successfully access their account using the recently updated password. This validation is performed through the accounts.login API, and a response with a status code of 200 is received, containing comprehensive user information.

Step 5 : According to SAP CDC, when a user logs in for the first time and their password is rehashed, you can double-check this by running a query: SELECT * FROM accounts WHERE profile.email=’ruchita.vanjari@acorel.nl’

**Important Note: –

To import data from external system to SAP CDC. it´s necessary to deactivate the “Email Verification” option. Without it, every record imported into SAP CDC the user will receive a confirmation email. Then, considering thousands of
records and the same number of sent email , also the dataflow gives an error saying Email verification policy is enabled.

Conclusion:

In conclusion, SAP Customer Data Cloud, coupled with Identity Sync Dataflow, revolutionizes customer experience by offering seamless migration and secure password hashing. With a focus on data security and user trust, this powerful duo empowers businesses to elevate customer engagement strategies and create meaningful interactions. Embrace SAP CDC and Identity Sync Dataflow to unlock the potential for extraordinary customer journeys and lasting connections.