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\Sensitive 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

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) :)

packages/DataProtection/src/Attribute/WithSensitiveHeaders.php

packages/DataProtection/tests/Integration/ObfuscateAnnotatedMessagesTest.php

packages/DataProtection/tests/Integration/ObfuscateChannelTest.php

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

packages/DataProtection/tests/Integration/ObfuscateChannelTest.php

packages/DataProtection/src/OutboundEncryptionChannelInterceptor.php

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

packages/DataProtection/src/Attribute/UsingSensitiveData.php

- 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

- solution provides obfuscation either for payload: either via Domain Message or entire channel - annotated Message will have precedence over channel configuration - obfuscating headers will be additional for message or default for channel as headers are not derivative from domain messages - annotating single endpoint, Ecotone will try to configure obfuscator for Message based on Payload

check license ensure data protection is applied on pollable channels ensure ChannelInterceptor::postReceive() modifies message when defined

…ception

add DataProtection test suite to phpunit.xml.dist file

packages/DataProtection/composer.json

packages/DataProtection/src/Attribute/Sensitive.php

dgafka · 2026-02-07T18:07:00Z

packages/DataProtection/src/Attribute/WithSensitiveHeader.php

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


Suggested change

#[Attribute(Attribute::TARGET_METHOD | Attribute::TARGET_CLASS | Attribute::IS_REPEATABLE)]

Attribute::TARGET_CLASS | Attribute::IS_REPEATABLE)]

same suggestion as for Sensitive, to keep it on the param level. There is also no point in decoding metadata, if we are not using that in param, which with current design would be possible.

I would keep this one as it is. just because header is not used in method parameters it can still be sent and if considered as sensitive, it should be obfuscated in queue.

Hmm, I think we should define the use case for those, because now they feel lacking intention, therefore being too generic,

If someone want's full encryption / decryption, then I would consider him going with attribute on top of class. (inbound/outbound scenarios)

And if someone would only handle decryption - Message coming from other system, Service Bus for example (Inbound scenarios)

If that's for inbound only, then it make to sense to keep it only for param, as we don't really care about the other ones.
wdyt?

@dgafka I think right now it makes no sense to differentiate whether message would come from other system or it was sent by the same application.

Whether this attribute should be omitted for TARGET_METHOD is a case for combining configuration from all sources - message, channel and endpoint - which would be trickier to understand why something was encrypted or not.

Right now, if Message is annotated, any other configuration will be skipped as Message will always have a priority - I'm thinking about future converter integration.

Lets keep it as it is. We can check how it is mostly used and adapt.

dgafka · 2026-02-07T18:10:44Z

packages/DataProtection/src/Obfuscator/Obfuscator.php

+use Ecotone\Messaging\Support\Assert;
+use Ecotone\Messaging\Support\MessageBuilder;
+
+readonly class Obfuscator


We are using different naming: Obfuscator, Sensitive, Data Protection.
Let's align it to Sensitive + Data Protection, dropping Obfuscator from Docs and Code?

Suggested change

readonly class Obfuscator

readonly class DataProtector

@dgafka obfuscation is one of the methods data can be protected. I remember we've been taking also about forgetable payloads. DataProtector sounds too general and doesn't describe what is actually done.

Hmm, I see. It feel to me that Obfuscator is naming that confuses, we are stating here about data protection using encryption and decryption. Like in here:

End user defines encryption key, but yet we describe the feature as obfuscation. This doesn't make things fully obvious for end user: is it actually related or something different (I personally got confused, when I started to review PR, and yet I knew the intention).

If we consider that data-protection may for example provide forgetable payloads too as a feature, then we this feature could be considered as Data Encryption (which is also searchable seo keyword, and rather widely used within community).

wdyt?

@dgafka in follow up PR I've dropped obfuscation related naming in favour of emphasizing on Message Encryption #626

packages/DataProtection/src/Configuration/DataProtectionModule.php

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 2 times, most recently 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

dgafka reviewed Jan 28, 2026

View reviewed changes

unixslayer added 9 commits February 5, 2026 22:15

tests for Event and Command Handler

b18aaea

add Enterprise license annotation

5d0bd45

- obfuscate full payload when message use sensitive data

2c72e37

- allow to define sensitive headers

bump ecotone version

0356036

cleanups

f02870a

tests cleanup

06bb11e

allow to configure data protection on:

12d51bb

- message - endpoint - channel

missing license annotation

2e8aaf3

unixslayer force-pushed the data-protection branch from 0e82dbf to 167e1d8 Compare February 5, 2026 21:16

unixslayer force-pushed the data-protection branch from 167e1d8 to 647a732 Compare February 5, 2026 21:31

unixslayer added 10 commits February 6, 2026 16:56

code review changes

510c25f

check license ensure data protection is applied on pollable channels ensure ChannelInterceptor::postReceive() modifies message when defined

sensitive headers can be defined in parameters

cad5aed

encryption key can also be defined with payload parameter

01be177

for stable API, payload parameter should have precedense

8c1bd67

skip on missing DataProtectionConfiguration instead of throwing an ex…

0b3c1e4

…ception

general cleanups

c38ef7e

array_find not available with php 8.2

393429f

bump requirement version

9d60798

remove lefover

c044c67

add DataProtection test suite to phpunit.xml.dist file

pipeline fix

b55df03

dgafka approved these changes Feb 7, 2026

View reviewed changes

dgafka merged commit 69f5981 into ecotoneframework:main Feb 7, 2026
9 of 10 checks passed


		use Attribute;

		#[Attribute(Attribute::TARGET_METHOD \| Attribute::TARGET_CLASS \| Attribute::IS_REPEATABLE)]

	#[Attribute(Attribute::TARGET_METHOD \| Attribute::TARGET_CLASS \| Attribute::IS_REPEATABLE)]
	Attribute::TARGET_CLASS \| Attribute::IS_REPEATABLE)]

Uh oh!

data protection #615

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!

Uh oh!

dgafka left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dgafka Feb 7, 2026

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dgafka Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

unixslayer Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

dgafka Feb 7, 2026

Choose a reason for hiding this comment

Uh oh!

unixslayer Feb 7, 2026

Choose a reason for hiding this comment

Uh oh!

dgafka Feb 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

unixslayer Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

unixslayer commented Jan 15, 2026 •

edited

Loading

unixslayer Feb 7, 2026 •

edited

Loading

dgafka Feb 8, 2026 •

edited

Loading