data protection #615

unixslayer · 2026-01-15T14:29:19Z

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
attribute can be defined with message, endpoint, or globally for channel
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
whole message payload will be encrypted with defined headers

Pull Request Contribution Terms

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

packages/DataProtection/src/OutboundDecryptionChannelInterceptor.php

packages/DataProtection/src/Configuration/DataProtectionModule.php

dgafka · 2026-01-17T08:07:11Z

packages/DataProtection/src/Configuration/DataProtectionModule.php

+            );
+            $messagingConfiguration->registerChannelInterceptor(
+                new OutboundDecryptionChannelBuilder($pollableMessageChannel->getMessageChannelName())
+            );


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

As this approach will have implications:

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

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.

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.

@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.

Encryption require source to be string.

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.

- 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 JMSModule to be enabled

- allow to define sensitive headers

- message - endpoint - channel

dgafka

Just some more coverage comments and potential API improvements.

I do think we can start with this and iterate over that (e.g. discuss how we want to handle Event Streams) :)

dgafka · 2026-01-28T17:17:19Z

packages/DataProtection/src/Attribute/WithSensitiveHeaders.php

+use Ecotone\Messaging\Support\Assert;
+
+#[Attribute(Attribute::TARGET_METHOD | Attribute::TARGET_CLASS)]
+class WithSensitiveHeaders


WithSensitiveHeader can be used multiple times, so we can drop this one?
That would also follow DX of other features like being able to put multiple CommandHandler attribute

dgafka · 2026-01-28T17:24:46Z

packages/DataProtection/tests/Integration/ObfuscateAnnotatedMessagesTest.php

+                        ->withKey('secondary', $this->secondaryKey),
+                    SimpleMessageChannelBuilder::create('test', $messageChannel),
+                    JMSConverterConfiguration::createWithDefaults()->withDefaultEnumSupport(true),
+                ])


can we add test case that using data protection without licence key fails?

dgafka · 2026-01-28T17:26:51Z

packages/DataProtection/tests/Integration/ObfuscateAnnotatedMessagesTest.php

+                    SimpleMessageChannelBuilder::create('test', $messageChannel),
+                    JMSConverterConfiguration::createWithDefaults()->withDefaultEnumSupport(true),
+                ])
+        );


Can we add test case where header is set to be sensitive, yet it's missing in message (I guess we should simply skip)

dgafka · 2026-01-28T17:29:00Z

packages/DataProtection/tests/Integration/ObfuscateChannelTest.php

+        self::assertEquals($metadataSent['bar'], Crypto::decrypt(base64_decode($messageHeaders->get('bar')), $this->primaryKey));
+        self::assertEquals($metadataSent['baz'], $messageHeaders->get('baz'));
+    }
+


Can we add test case that it fails on setting up channel protection on non pollable channel?

dgafka · 2026-01-28T17:31:44Z

packages/Ecotone/src/Messaging/Channel/PollableChannelInterceptorAdapter.php


        foreach ($this->sortedChannelInterceptors as $channelInterceptor) {
-            $channelInterceptor->postReceive($message, $this->messageChannel);
+            $message = $channelInterceptor->postReceive($message, $this->messageChannel);


Can we add single test case for such interceptor modifying result in main Ecotone package?
Just to be aware if we break this functionality without the need to run whole test suite.

dgafka · 2026-01-28T17:35:37Z

packages/DataProtection/tests/Integration/ObfuscateChannelTest.php

+        self::assertEquals($metadataSent['bar'], Crypto::decrypt(base64_decode($messageHeaders->get('bar')), $this->primaryKey));
+        self::assertEquals($metadataSent['baz'], $messageHeaders->get('baz'));
+    }
+


Can we add a test case where we encrypt only headers without payload?

dgafka · 2026-01-28T18:40:20Z

packages/DataProtection/src/OutboundEncryptionChannelInterceptor.php

+        $routingSlip = $message->getHeaders()->get(MessageHeaders::ROUTING_SLIP);
+
+        foreach ($this->messageObfuscators as $routing => $obfuscator) {
+            if (str_starts_with($routingSlip, $routing)) {


That may fail if we have something like 'stocks', 'stocks_public'.

There should be method hasPrecedingRoutingSlip or something like in MessageHeaders to compare equally (if not we can add)

But we are targetting current channel, so maybe we can just inject channel name here and compare instead?

dgafka · 2026-01-28T18:43:52Z

packages/DataProtection/src/OutboundEncryptionChannelInterceptor.php

+
+        if ($routingObfuscator = $this->findRoutingObfuscator($message)) {
+            return $routingObfuscator->encrypt($message);
+        }


Can we have test where we define sensitive data on channel and message to define the expected behaviour?

I would suspect we either throw exception, or we put precedence on message configuration

dgafka · 2026-01-28T18:49:07Z

packages/DataProtection/tests/Fixture/ObfuscateAnnotatedEndpoints/TestCommandHandler.php

+    #[UsingSensitiveData]
+    #[WithSensitiveHeaders(['foo', 'bar'])]
+    #[WithSensitiveHeader('fos')]
+    public function handleFullyObfuscatedMessage(


a) Can you explain the use case we are trying to solve with encryption on the level of command handler, if we have this on level of Message?

b) If Message would come from different Service and our use case would be to decrypt headers, then we could make the api more explicit here

#[Sensitive] #[Header('foo')] $some

Not a blocker for this PR, we can follow up with potential changes with next PRs

dgafka · 2026-01-28T18:50:44Z

packages/DataProtection/src/Attribute/UsingSensitiveData.php

+use Attribute;
+
+#[Attribute(Attribute::TARGET_METHOD | Attribute::TARGET_CLASS)]
+class UsingSensitiveData


Suggested change

class UsingSensitiveData

class UsingSensitivePayload

We define Header, and in documentation we do mention that Message contains of Headers and Payload, therefore that would be in relation to our domain language

unixslayer requested a review from dgafka January 15, 2026 14:29

dgafka reviewed Jan 17, 2026

View reviewed changes

unixslayer force-pushed the data-protection branch from 732ba0d to ff23dab Compare January 19, 2026 17:04

unixslayer added 8 commits January 21, 2026 15:57

tests for Event and Command Handler

36b8881

add Enterprise license annotation

88cf4ca

- obfuscate full payload when message use sensitive data

0844536

- allow to define sensitive headers

bump ecotone version

7e8c745

cleanups

68027ca

tests cleanup

dce6948

allow to configure data protection on:

dac7750

- message - endpoint - channel

unixslayer force-pushed the data-protection branch from 7460dca to dac7750 Compare January 23, 2026 20:44

unixslayer marked this pull request as ready for review January 23, 2026 20:44

unixslayer requested a review from dgafka January 23, 2026 20:44

missing license annotation

0e82dbf

dgafka reviewed Jan 28, 2026

View reviewed changes

Uh oh!

data protection #615

Are you sure you want to change the base?

data protection #615

Uh oh!

Conversation

unixslayer commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why is this change proposed?

Description of Changes

Pull Request Contribution Terms

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dgafka left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

unixslayer commented Jan 15, 2026 •

edited

Loading