Why Axon GDPR Data Protection Module?
The Axon Data Protection module isn't a new run-time component to manage. It's just a Java library, distributed as a jar file together with sample test code, API docs, and a reference guide. After installing the jar in your local Maven repository or your organization's artifact server, you can include it as a dependency in your project and start using it. To store keys for real, you'll need to configure the module to use a database or other key management system. Still, to make development easy, we have also included a no-configuration in-memory key management system for use during unit tests.
The Axon Data Protection module has an explicit API method to encrypt and decrypt objects. Still, to make integration of the module in an Axon application even easier, it includes a FieldEncryptingSerializer. This serializer will encrypt before serialization and decrypt before deserialization. This will minimize the amount of effort needed to integrate. Because the Serializer interface is Axon-specific, and because it has changed between Axon versions, we ship 4 versions of the Axon Data Protection module: for use in Axon 4, Axon 3, or Axon 2, and use without Axon Framework at all. And, as we know that many JVM developers are looking beyond vanilla Java nowadays, we have made sure that the library integrates easily with Kotlin en Scala.
Supporting Complex Objects
In simple cases, you may be looking to encrypt some individual String fields in an event object. In real-world cases, things could also get a lot more complex; events may contain other objects which contain personal data or various collections thereof. And it may not just be about Strings; dates, numbers, byte arrays, and other data types may contain personal data as well. The Axon Data Protection module supports arbitrarily complex object graphs (including cyclic ones!) and handles all these cases well. It is known to deal with collections, distinguish between immutable and mutable ones, and understand both the Java and Scala collection hierarchies.
So, what happens if you're decrypting an object while the encryption key has already been erased? It's up to you. By default, the module would, in this case, render String fields empty, set primitive fields to their type's default, and make other fields null. But alternatively, you might configure the module to set it to some other value, throw an exception, show part of the original cleartext, or anything else. It's flexible. Similarly, you may choose to use one key per object or multiple keys, and you may use one of the standard ways to store keys or implement your own. The module provides reasonable, easy-to-use default while at the same time providing hooks to customize the behavior if desired.