Page History
| HTML |
|---|
<style>
.release-box {
height: 30px;
width: 100px;
padding-top: 8px;
text-align: center; border-radius: 5px;
font-weight: bold;
background-color: #828995;
border-color: #FCE28A;}
.release-box:hover {
cursor: hand;
cursor: pointer;
opacity: .9;
}
</style>
<meta name="robots" content="noindex">
<div class="release-box">
<a href="https://docs.perspectium.com/display/Lithium" style="text-decoration: none; color: #FFFFFF; display: block;">
Lithium
</a>
</div> |
| Anchor | ||||
|---|---|---|---|---|
|
With ServiceNow's deprecation of the GlideEncrypter API (used for Triple DES encryption) and its current planned removal by Q4 2025, there are a couple different approaches for encrypting data shared out of your ServiceNow instance with the Perspectium integration.
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
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.
| Warning |
|---|
It is suggested not to use TripleDES with the default approach as there will be performance issues since the third-party JavaScript library is substantially slower than the GlideEncrypter API. This is due to the library being executed externally at the client platform level whereas ServiceNow APIs are ran at a lower platform level with more direct access to the data. As well, Triple DES as a security encryption standard is no longer a recommended option per NIST-800-131A (and the reason ServiceNow is removing GlideEncrypter). It is recommended you change to use a more secure encryption method like AES128 or AES256 for configuring your (bulk and dynamic) shares when using the default approach. The AES encryption methods also use a third-party JavaScript library but are using a different library that has been optimized (since Triple DES is no longer considered a secure encryption method, third-party libraries are limited in their support, maintenance and optimization). |
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.
| Info | ||
|---|---|---|
| ||
|
Set Up
To set up this approach do the following:
| UI Steps | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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:
| Code Block |
|---|
{
"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.