Skip to content

data protection#615

Merged
dgafka merged 20 commits intoecotoneframework:mainfrom
unixslayer:data-protection
Feb 7, 2026
Merged

data protection#615
dgafka merged 20 commits intoecotoneframework:mainfrom
unixslayer:data-protection

Conversation

@unixslayer
Copy link
Member

@unixslayer unixslayer commented Jan 15, 2026

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.

@unixslayer unixslayer requested a review from dgafka January 15, 2026 14:29
@unixslayer unixslayer force-pushed the data-protection branch 2 times, most recently from 7460dca to dac7750 Compare January 23, 2026 20:44
@unixslayer unixslayer marked this pull request as ready for review January 23, 2026 20:44
@unixslayer unixslayer requested a review from dgafka January 23, 2026 20:44
Copy link
Member

@dgafka dgafka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- 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
- 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
"ext-openssl": "*",
"ecotone/ecotone": "~1.298.0",
"ecotone/jms-converter": "~1.298.0",
"defuse/php-encryption": "^2.4"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Image

This one seems to be abandoned. Is there some other lib we can rely on?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dgafka there are two alternatives I can think of

  1. take defuse/php-encryption as internal package (like ecotone/php-encryption) and support it
  2. use https://github.com/phpseclib/phpseclib

First approach seems reasonable with minimal effort as it uses php functions (openssl_encrypt and openssl_decrypt) and covers 100% what we need.

phpseclib is widely supported but it seems excessive in area we actually need.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Ok, let's then start by taking over that package into our ecotone/data-protection


use Attribute;

#[Attribute(Attribute::TARGET_METHOD | Attribute::TARGET_CLASS | Attribute::IS_REPEATABLE)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@unixslayer unixslayer Feb 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

use Ecotone\Messaging\Support\Assert;
use Ecotone\Messaging\Support\MessageBuilder;

readonly class Obfuscator
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@dgafka dgafka Feb 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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?

continue;
}

$messagingConfiguration->registerChannelInterceptor(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we only register if encryption is meant to be used? Otherwise each polling channel will be decorated in the call stack

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

at this point we don't know if given channel handles sensitive message, this is done inside of the interceptor which accepts reference to channel obfuscator (if defined for given channel) and all message obfuscators. once we integrate message protection with serialization we can change this part.

@dgafka dgafka merged commit 69f5981 into ecotoneframework:main Feb 7, 2026
9 of 10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants