Default Approach of Encrypting Each Record Individually

The default approach encrypts data the way it has been since the Perspectium Core application for ServiceNow was first developed, with you choosing the encryption method to encrypt each record individually during sharing as each record is put into the outbound (psp_out_message) table to be sent to the Perspectium Integration Mesh. The records are encrypted using the encryption key specified in the shared queue used with the share.

With the deprecation of GlideEncrypter, TripleDES is still available as an option for the Encryption Method selection on bulk and dynamic shares but will use a third-party JavaScript library for doing the encryption in place of GlideEncrypter.

↑ Go to top of page

Encrypting Content Sent to MBS Approach

With Lithium 9.0.0+ and newer, there is an alternative approach for encrypting the content as it is sent to the Perspectium Integration Mesh (MBS).

Whereas the default approach will encrypt each record one by one (i.e. when you go to Perspectium > Messages > Outbound > Outbound Messages and open up a record, you will see the record is encrypted as stored in the Value field and you have the Decrypt value option to decrypt and see the actual record being shared), this approach will do one encryption of all the records in the batch at the same time before it is sent to MBS.

The sharing of data to put the records into the outbound table (psp_out_message) will only base64 encode the records since ServiceNow makes a Base64 API available that will performance similar to GlideEncrypter.

Then when the Perspectium Core application runs its scheduled job to take a batch of records from the outbound table (psp_out_message) and send those to MBS, the batch will first be encrypted using the encryption key specified in the shared queue used with the share before being sent to MBS.

We are still using third-party JavaScript libraries since GlideEncrypter is not available but by only encrypting the entire batch this will allow us to have better performance versus encrypting each record one by one. Because Triple DES is not considered a secure encryption method, this approach only supports AES128 and AES256 encryption methods.

Set Up

To set up this approach do the following:

2024-08-18 20:12:25.776 INFO  - live_demo_subscribe - SubscriberTask - received an array of 1 elements
2024-08-18 20:12:25.777 INFO  - live_demo_subscribe - SubscriberTask - element is message with topic encrypted_messages and name messages.bulk with 10 records
2024-08-18 20:12:25.791 INFO  - live_demo_subscribe - SubscriberTask - received an array of 10 elements

Encrypted Batch Message

As the Perspectium Core application batches up the records and encrypts the batch to send to MBS, it will store this batch in a Perspectium message in JSON format as follows:

{
	"topic": "encrypted_messages",
	"type": "servicenow",
	"name": "messages.bulk"
	"key": "<your_servicenow_instance_name>", (ie. "dev12345")
	"value": "<encrypted_batch_of_records",
	"attributes" "<addtional_message_attributes>"
}

We use our standard Perspectium message format with specific properties for the topic, type and name so that target applications (DataSync Agent, meshlets and Perspectium Core on a subscribing ServiceNow instance) reading this message know this is an encrypted batch of messages to then decrypt first before doing the regular processing of each message.

↑ Go to top of page