The Temporal way would be either not passing sensitive information directly through the workflow or encrypting it before submitting to the service.
Both Java and Go SDK use the DataConverter interface to serialize and deserialize workflow and activity function arguments and results. We recommend creating your own version of DataConverter that encrypts payloads that have to be hidden using whatever library and certificate management solution your company prefers.
Thanks @maxim I have been exploring the way to encrypt the sensitive info before passing it to temporal.
I built a working solution using Jackson Crypto (https://github.com/meltmedia/jackson-crypto) and java samples of temporal.
Here find below the github sample app based on java samples:
Have you looked into implementing the DataConverter interface to support encryption? This way the workflow and activity code don’t need to deal with encryption directly.
Thanks @maxim for encouraging to use a better practice of custom DataConverter instead of making workflow and activities to deal with encryption.
Now I have improved the sample to use
Custom DataConverter (via WorkflowClient options) -> which uses Custom JacksonJsonPayloadConverter (this is where encryption code resides).
Now in temporal web “input” and “result” both show in encrypted JSON format while passing through. Whereas in my application I’m still getting original POJO for utilization. This exactly what I wanted.
Please have a glance at below code if in case I’m doing it wrong or doing too much.
Looks good to me. One option would be extending the JacksonJsonPayloadConverter and use the constructor that takes ObjectMapper instead of completely rewriting it.
So now after enabling encryption in my application using custom data converter, started facing a new issue where signup workflow starts failing and gets retried again and again.
I am suspecting it is due to some delay introduced bcoz of encrypt / decrypt logic, and hence temporal data conversion is getting timed out. What do you think ?
For second question’s answer did jmeter perfomance testing on jackson-json-crypto library was surprised to learn that it indeed was taking more than a second under stress of just 15 threads.
Found the issue in pre-configured iterationCount for below java method, which was very high.
Then configured it to a little moderate iteration count.