everest-engineering/axon-crypto-shredding-extension

Crypto shredding for Axon

axon-crypto-shredding-extension's Issues

EncryptionAutoConfiguration is not an auto configuration

Hi,

In your library there is a EncryptionAutoConfiguration. However, this is not an auto configuration, as your jar file does not contain a META-INF/spring.factories file. Such a file should contain something like

org.springframework.boot.autoconfigure.EnableAutoConfiguration=engineering.everest.axon.cryptoshredding.encryption.EncryptionAutoConfiguration

Maybe it would also be a good idea to provide a separate module for the Spring adapter. Otherwise you force the Spring libraries into the dependency tree.

Better abstraction for the SecretKeyRepository

Hi,

Currently your library uses the SecretKeyRepository which is basically a JPA repository. This forces the usage of JPA and a shared database between the micro services, which is not always desired. Maybe it would be a nice feature to use a simpler interface (with the methods create, save, findById). You could then provide a default implementation which uses JPA. Other implementations could, for instance, use queries and commands to access a shared key store.

DefaultAesEncrypterDecrypterFactory shouldn't be package visible

Hi,

Currently the only implementation of the EncrypterDecrypterFactory is the package-visible DefaultAesEncrypterDecrypterFactory. Without using the Spring EncryptionAutoConfiguration (or without reflection), it is not possible to use the DefaultAesEncrypterDecrypterFactory. Therefore this class should have the public modifier.

DefaultAesKeyGenerator shouldn't be package visible

Hi,

Currently the only implementation of the KeyGenerator is the package-visible DefaultAesKeyGenerator. Without using the Spring EncryptionAutoConfiguration (or without reflection), it is not possible to use the DefaultAesKeyGenerator. Therefore this class should have the public modifier.

Improve the API for fields that cannot be decrypted anymore

Hi,

Currently the library has two issues when it comes to replaying events that cannot be decrypted anymore due to a deleted key:

1. The default value cannot be changed. This is especially problematic for us, as we are heavily relying on not-null-constraints on our events. If a field suddenly becomes null, the event cannot be deserialized anymore. It should be possible to provide some kind of function for the default-values.
2. It doesn't seem to be possible for the event handler to recognize such events. It would be very helpful, it we could at least set some kind of flag within the event to check whether the event can no longer be fully decrypted. Maybe we could add a specific annotation to a boolean field, which is not serialized, but rather filled during the deserialization/decryption?

Remove guava dependency

Hi,

guava is a library which is often used in various projects and leads very often to version conflicts. In my experience libraries should almost never use guava - only applications should use it. You are currently using the library only for a single method - to find default values for fields that cannot be decrypted. I suggest to move the required code into your library and to remove guava as dependency.

Show the maven coordinates in the Readme file

Hi,

Your extension is clearly deployed to maven central:

<dependency>
  <groupId>engineering.everest.axon</groupId>
  <artifactId>crypto-shredding-extension</artifactId>
  <version>...</version>
</dependency>

I think it would be helpful if those coordinates would be visible in the readme file which is shown on the first page of your Github project. Maybe even use a maven badge.

Make the key extractor configurable

Hi,

Currently, the CryptoShreddingSerializer has a hardcoded logic for extracting the key (in the convertToString method) and knows Strings, UUIDs, Longs, and Integers. However, we usually use specific classes for the ids. For instance, if we have an aggregate Customer, we would have a class CustomerId which wraps an UUID. It would therefore be useful if we could configure the key extractor somehow. This would basically be a function from the key object to String.