data protection

[unixslayer]

Why is this change proposed?

Sensitive data should be obfuscated when leaving application via transport channels.

Description of Changes

• use Ecotone\DataProtection\Attribute\UsingSensitiveData to define messages with sensitive data
• use Ecotone\DataProtection\Attribute\Sensitive to mark properties with sensitive data
• define encryption keys with Ecotone\DataProtection\Configuration\DataProtectionConfiguration
• sensitive data will be encrypted right before its sended to queue and decrypted right after message is being retrieved from queue
• data protection require JMSConverter module to be enabled

Pull Request Contribution Terms

• I have read and agree to the contribution terms outlined in CONTRIBUTING.

[dgafka]

What is the reason to do the hooking via Channel Interceptors?

As this approach will have implications:

1. So far we only deserialize the message payload when it's actually being used (not after it's fetched from channel). This is to ensure higher performance.
   As some Event Handler could for example use only Headers, so there is no need to deserialize payload. The other case is that outbox may be pushing message from db channel to rabbit channel. In this scenario there is no need to deserialize message when it's fetched, only to serialize it again to push it to other channel

2. With current implementation, we do inside round trips, meaning:

• we get serialized message before it's pushed to channel,
• deserialize it to encrypt,
• serialize again with encryption encrypted.

3. How you give a thought about enriching our current internal Converter/Conversion mechanism? As this would work earlier the in flow, so potentially it should have above drawbacks, and would work naturally with different media types.

[unixslayer]

@dgafka I've been struggling with using Conversion mechanism for that. There are few problems with that approach that I don't see how to resolve.

1. Encryption require source to be string.
2. Converters do not chain nor can't be wrapped. First applicable converter will be used.

To use Conversion mechanism it will require a lot of ground refactoring and even then I expect it will be heavy and complicated as sensitive properties can have custom converters already which do not have to convert to/from string. Hooking into Channel Interceptors is easier as message is already serialized into expected media type.

Also, behavior for encryption depends more on endpoint itself rather than message as for some endpoints (as You've already noticed) may use only headers I see it possible to define endpoint as sensitive which with introduced approach allow for following definitions:

#[CommandHandler|EventHandler]
#[UsingSensitiveData(encryptionKeyName: 'gcp-key')]
public function doStuff(#[Payload] Message $message): void
{
    // ...
}

#[CommandHandler|EventHandler]
#[UsingSensitiveData]
#[WithSensitiveHeaders(headers: ['foo', 'bar'])]
public function doStuff(#[Header('foo')] string $foo): void
{
    // ...
}

#[CommandHandler|EventHandler]
#[UsingSensitiveData]
#[WithSensitiveHeader(header: 'foo')]
public function doStuff(#[Header('foo')] string $foo): void
{
    // ...
}

Again, when hooking into channel interceptor it is possible to configure it based on endpoint definition and to see if payload actually needs to be encrypted. I think when using converters there is no way to do that. Or at least it is not easy which will only complicate whole implementation.