0

I have an event, let's say order.placed The payload consists of some general information about the order and 3 confidential fields. For example part of the message should only be visible to consumer A, part to consumer B and part to consumer C.

Does any pattern exist to handle this kind of requirement?

I considered encrypting these parts of the message with different keys, so only consumers for which this data should be available be able to decrypt this part of message.

I also thought about sending the same message with three different payloads for each consumer.

Have you tried any of these approches, maybe there are others?

Improve this question
5
  • If consumers can only read part of the message, you essentially have three message types. Can you tell use what the encrypted fields are and why the consumers aren't allowed to see them?
    – Ewan
    Commented Feb 1 at 15:27
  • Some sensitive information, let's say payment details, which are not required by loyalty service to do it's job. All of the services care about order.placed but each of them need slightly different set of data, of which some is sensitive and it doesn't seem right for me that I give every service the possibility to read that data.
    – Kamil Latosinski
    Commented Feb 1 at 15:47
  • I mean it sounds like payment data would be on payment.made rather than order.placed? is the problem that you have only a few, large, events with lots of data?
    – Ewan
    Commented Feb 1 at 17:37
  • im just thinking obviously sensitive stuff like payment details, you would expect to be excluded from most events, what kind of event do you have that has 3 different kinds of secret data
    – Ewan
    Commented Feb 1 at 17:38
  • If you go with the encryption approach, you need to implement some sort of key management you should have a plan for what you will do if/when a key is compromised. Also realize that if you are using PKI for this, the overhead of encryption and decryption is a lot higher than what you see with typical HTTPS interactions.
    – JimmyJames
    Commented Feb 2 at 15:35

2 Answers 2

Reset to default
2

Another approach/option is to send one message with the minimum amount of information so every consumer can use the message. Once the message is read, they could call an API => getOrderDetails() which will return additional information. Assuming they authenticate, the API can authorize which part(s) order details can be sent to the caller of the API.

This way the message doesn't have any logic inside of it of what parts can be read by individual consumers.

Improve this answer
5
  • One of the benefits of an event driven architecture is to not have this kind of dependency.
    – Rik D
    Commented Feb 1 at 20:35
  • Yes, I did consider that, however the big downside of that approach is increased load on the producer. But it's one of the options.
    – Kamil Latosinski
    Commented Feb 1 at 20:48
  • Thanks for the comment. Probably different messages/queue for each consumer type. You could control access that way and ensure no data (encrypted or otherwise) would be in message/queue for a particular consumer type. So, each message has exactly what is needed and nothing more.
    – Jon Raynor
    Commented Feb 1 at 20:59
  • @RikD That's true, to a point. In practice, I find that this kind of approach is necessary to make such systems robust. It can also be a much simpler solution for many problems that can be difficult or even intractable with a pure event-driven design.
    – JimmyJames
    Commented Feb 2 at 15:20
  • "the big downside is increased load on the producer" I think I understand your point but it's not really that cut-and-dried. A lot of that depends on the architecture of your solution. For example, the size of messages in such an approach can be much smaller, reducing the load and storage requirements for your messaging platform.
    – JimmyJames
    Commented Feb 2 at 15:25
1

It seems unusual to have data in an internal communication between software services that should be visible to some consumers and hidden from others. So I would guess that there isn't a common pattern for this situation.

That said, if you really need it, either of your approaches would work (as it would when communicating with external untrusted entities).

Improve this answer
3
  • Good point. For example loyalty service doesn't need data that is designated for payment service. It bothered me that it might be kind of a security issue that my loyalty service can read payment data from the message, but maybe it's not that big of an issue and I should trust my own services.
    – Kamil Latosinski
    Commented Feb 1 at 15:46
  • I think you might be breaking some laws, or at least annoying your bank, if you start sending unencrypted cc details around needlessly
    – Ewan
    Commented Feb 1 at 17:41
  • The payment details is just an example out of the blue. I'm not sending cc details around. For the discussion we can just assume it's secret data, whatever that is.
    – Kamil Latosinski
    Commented Feb 1 at 20:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.