Form Prefill for Anonymous Users

   Journey Manager (JM) The transaction engine for the platform.  |    Platform Developer  |  All versions This feature is related to all versions.

Manager offers a wide range of options to support form prefill or pre-population including anonymous users.

There are several options for different use cases, which are safe to use for Personally Identifying InformationPersonally Identifiable Information (PII) is information about an individual that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and any other information that is linked to an individual. In Europe, PII is known as personal data. data meaning they are only to be used to pass non PII data, such as a product choice on a website.

It should be mentioned that a term Anonymous is actually a bit misleading. The user might be authenticated in another system, they are just not a registered user in Manager.

You can solve this problem There are several options when tackling this problem.

• URL Parameter passing on a GET request
• HTTP request headers on a POST request
• Cookies
• Short life tokens
• Encrypted string

URL Parameter passing on a GET request

It doesn't get much simpler than this. All you need to do is add some form prefill mappings using the same name as the URL parameter you use as shown below.

Would work with a url such as https://tm.demo.avoka.com/test/servlet/SmartForm.html?formCode=cgf-apply-ga&product=single&productTerm=Fixed&quoteID=GTM495780

Pros

• Very simple
• Out of the box

Cons

• It should only be used for non sensitive or PI data i.e. you should not be passing data such as the customer name

HTTP request headers on a POST request

This is pretty much the same mechanism as the above method but the data name/value pairs our provided as header attributes on the POST request. This implementation is very common in our solutions.

The example is shown below

The Manager config is exactly the same.

Pros

• Simple
• Out of the box
• Slightly more sophisticated than URL parameters

Cons

• It should only be used for non sensitive or PI data i.e. you should not be passing data such as the customer name

Encrypted Cookies

This is not an out of the box option and requires the creation of a custom form component and two TM groovy services.

The service requires three components:

• Cookie Manager (Composer/Maestro widget) - added to the form
• XXXCLIENT Cookie Decryption (Transact Dynamic Data service) - called by the Cookie Manager widget
• XXXCLIENT Cookie Encryption (Transact Submission Completed Processor service) - associated with the form

How it operates:

• XXXCLIENT Cookie Encryption: extracts form values from the "XXXCLIENTData" node and populates an encrypted cookie named "XXXCLIENTData".
• Cookie Manager: holds data fields populated from the encrypted "XXXCLIENTData" cookie. Also hold a business rule that invokes the "XXXCLIENT Cookie Decryption" dynamic data service to decrypt the contents of the cookie. The business rule is only invoked once during the form's initialization phase.
• XXXCLIENT Cookie Decryption: Dynamic data service invoked via form business rule within the Cookie Manager widget.

On submission the data from the form is encrypted and made available to any subsequent form in the solution that the user might access.

Pros

• Fairly secure

Cons

• Relies on the next form being opened on the same device

Short life tokens (SLT)

There are often several client systems from which secure Personally identifiable informationPersonally identifiable information (PII) is any data that could potentially identify a specific individual. Any information that can be used to distinguish one person from another and can be used for de-anonymizing anonymous data can be considered PII. (PII) can be sourced. For this reason, Manager provides a simple reusable prefill implementation that can be consumed by several “client system” sources, such as:

• Online Banking
• Customer portals
• CRM

Manager exposes a RESTful service to enable the “client system” to push customer data to Manager when a customer requests the form from within the “client system” application. Manager passes back a unique identifier (UUID) that will enable the client system to build a URL request that will open the form with the prefilled data.

Prior to Manager 5.0, implementations of a "container" submission are used to store the data. Since Manager 5.0, storing the temp prefill data in MemCache for the very short time is possible and is a neater design than creating a temporary submission object to hold the prefill data for a short time frame.

The token will be short lived, if the UUID (submitkey) passed is for a container submission older than 30 seconds (configurable), Manager loads an empty form. The container will be removed.

If the form prefill is successful, the form will load, and the container will be removed.

A tidy up task will be scheduled to remove any containers older than 1 minute.

If the RESTful customer data service (2) is unsuccessful the UUID will not be returned.

If the form prefill service in Manager fails for one of the reasons below, it will load an empty form.

For the prefill service call (2), IP whitelisting and basic auth. will be used to secure access.

Several URL parameters will need to be passed with the Request (5):

Example prefill data provided could be:

• Salutation
• First Name
• Last name
• Date of birth
• Address
• Mobile
• Email

Pros

• secure option
• single prefill service required in Avoka
• securely pass data from multiple sources

Cons

• does require some work by the client

Encrypted String

This is an enhancement on the prefill mapping GET or POST request, rather than sending name value pairs in clear text you encrypt all your prefill data into a single string. This is not a common implementation.

Generally the outline is as follows:
 # A public/private key pair is generated for the TM instance. The encryption (public) key is shared with the external calling site/portal.
 # The external (referring) website/portal generates the secure token and adds this to the HTTP request, either in the payload data or as a request cookie.
 # The TM prefill service parses the token from the request, decrypts and prefills the form per BAU.
 
The encryption / decryption code is largely boiler-plate Java code and easily transportable, e.g.:
/**
 * Encrypts or decrypts the specified byte value
 * Presumes that the decryption value has been Base64 decoded already, e.g.:
 * def URLCodec urlcodec = new URLCodec()
 * def byte[] value = urlcodec.decode(aString).decodeBase64()
 * Presumes that the encrypting value is in UTF-8 encoding, e.g.:
 * byte[] value = aString.getBytes("UTF-8") * 
 * @param value
 * @param encrypt
 * @param keystore
 * @param keystorePass
 * @param keyAlias
 * @param aliasPass
 * @return byte[]
 */
private byte[] encryptDecrypt(byte[] value, boolean encrypt, byte[] keystore, String keystorePass, String keyAlias, String aliasPass) {
 // access the keystore and load the decryption key
 KeyStore keyStore = KeyStore.getInstance(KeyStore.defaultType)
 ByteArrayInputStream bais = new ByteArrayInputStream(keystore)
 keyStore.load(bais, keystorePass.toCharArray())
 Key key = keyStore.getKey(keyAlias, aliasPass.toCharArray())
 int keyBuffer = key.getModulus().bitLength() / Byte.SIZE
 Certificate certificate = keyStore.getCertificate(keyAlias)
 Cipher cipher = Cipher.getInstance(key.algorithm)
 // encryption
 if(encrypt) {
 cipher.init(Cipher.ENCRYPT_MODE, certificate.publicKey)
 ArrayList encryptedArray = []
 value.toList().collate(keyBuffer-11).each() { bytes ->
 def encryptedData = cipher.doFinal((byte[])bytes)
 encryptedArray.addAll(encryptedData)
 }
 return (encryptedArray as byte[])
 }
 // decryption
 else {
 cipher.init(Cipher.DECRYPT_MODE, key)
 StringBuffer decryptedStr = "" << ""
 value.toList().collate(keyBuffer).each() { bytes ->
 def decryptedData = cipher.doFinal((byte[])bytes)
 decryptedStr << new String(decryptedData)
 }
 return decryptedStr.toString().getBytes("UTF-8")
 }
}

Pros

• Fairly secure
• Prefill data is encrypted.
• It can be a little more flexible to a roll-you-own solution without resorting to more structured models (like SAML).

Cons

• For larger payloads, encrypted data will need to be sent as a POST request.
• Encryption keys need to be maintained (on both sides).
• Prefill data is encrypted. Debugging and operational support becomes more difficult.

Next, learn about form property prefill mapping.