Digital Messaging Security
You have several options for ensuring secure communications when using the Web Messaging channel.
- Allowed domains: Sets the domains where the Chat widget can be deployed (Cross Origin Resource Sharing security)
- Allowed cookies: Can be used to transmit public information available from the user's browser
- JWT secret: Protects the customer's private data by using a public/ private key exchange
Configuring security settings
U+ Bank wants to ensure that the Web Messaging widget can be deployed only on its websites. The bank also wants to protect the transmission of a customer's private data. To implement the business scenario, click Channels and then select the Retail bank digital messaging channel interface.
On the Channels tab, click Manage connections to open the Digital Messaging Manager.
In the Digital Messaging Manager, click Retail bank to open the web messaging connection.
Click the Security tab to add the security settings for the connection.
Setting an Allowed Domain
U+ Bank wants to set an Allowed domain to validate that the U+ web site can securely render the Web Messaging widget. This option uses Cross-Origin Resource Sharing security (CORS), which allows a server to indicate any other domain than its own from which a browser should permit loading of resources.
In the Allowed domains section, in the New domain field, you enter the URL of the website that is valid to render the new chat widget, and then click Add. For U+ Bank, the URL is: https://www.uplusbank.com
You can add more than one domain to the Allowed domains section. Adding the domains here validates that the websites can securely render the Web Messaging widget on their web pages. The widget cannot load on any websites except for the sites configured in this section. If you do not enter any domain, or enter *, the Web Messaging widget renders on any website.
In this example, U+ Bank can also use the chat widget on account.uplusbank.com or uplusbank.com/store. If the bank wants to use the chat widget on www.uplus.com, it needs to add that entry to the Allowed domains section.
Setting Allowed Cookies
For example, U+ Bank customers initiate a chat session from the bank's website. U+ Bank uses a cookie that associates the customer's current website location, the page viewed, with the customer Cart Contents. The cookie helps the customer service representative to direct the customer to appropriate site content.
In the Allowed cookies section, in the New cookie field, add the file name of the cookie, and then click Add.
Caution: Cookies should not be used to pass customer's private data, such as login credentials.
As an alternative to using a cookie, you can use customer Context Data to pass information to the Pega Customer Service implementation. The Context Data is automatically visible to the CSR when they are assigned an escalating chat. The cookie data is attached to the interaction but is meant to be used by an internal process, for example, to update the customer status or the case progress. Cookie data would not necessarily be viewed by the CSR.
Using the JWT Secret to sign requests
The JWT Secret option lets you use a JSON Web Token (JWT) to protect a customer's private data. The JWT Secret uses a public/private key exchange to confirm the customer's identity.
In the JWT Secret section, click Show JWT Secret to view the token.
U+ Bank uses the JWT API token to sign requests while exchanging private data.
Caution: To use the JWT Secret to pass data to Pega Customer Service, you need to set up the processes described in the CustomerSecretData Implementation Guide. The JWT token is used by your website backend server to pass the CustomerSecretData to the chat server for inclusion with the customer chat messages. This can be used for data like Authentication Status, or Customer ID, where you do not want to include this data on the webpage.