🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Message Sender Identity
I have used the JMSXUserId to maintain message sender identity but noticed this feature isn’t available when using certificate authentication. Is there a comparable way to securely identify the message senders identity when using certificate authentication.
Best Answer
-
Interesting find! As you are probably thinking, I believe it would be ideal for the "common name" of the cert to be used for this and will follow up internally to see if I'm missing something or if an enhancement can be added in the future for that.
In the meantime, since the JMSXUserID doesn't seem to be set when using certificate authentication one way I can think to do it would be to set the "JMSXUserID" (or another custom String property if you prefer) on the message prior to sending it. You should be able to do this using the
javax.jms.Message.setStringProperty(String name, String value)method.6
Answers
-
Interesting find! As you are probably thinking, I believe it would be ideal for the "common name" of the cert to be used for this and will follow up internally to see if I'm missing something or if an enhancement can be added in the future for that.
In the meantime, since the JMSXUserID doesn't seem to be set when using certificate authentication one way I can think to do it would be to set the "JMSXUserID" (or another custom String property if you prefer) on the message prior to sending it. You should be able to do this using the
javax.jms.Message.setStringProperty(String name, String value)method.6 -
I agree with your concern about the potential of spoofing by the producers, but you could potentially lesson this concern by restricting what certificates you trust and/or tightening ACL Profiles to restrict what endpoints a client can publish to.
As a follow-on to my previous post: our team is looking into potentially allowing the Username source (by default "common name") to be used for the JMSXUserID when using client cert auth, but to be clear, at this point I don't have an answer of if they will do it or when it will be done. If you happen to know of another broker that allows this let me know and I'll pass it along to the team.
1 -
Hi @Artem_B,
Unfortunately this has not been implemented and it was estimated as quite a bit of work so I don't think it will be added anytime soon. That said, if you're a paying customer please open a support ticket as that will sometimes help get enhancements prioritized.
@Aaron / @TomF any other ideas for verifying message sender identity?
0 -
As @marc alluded to, the Solace-y way to do this would be to restrict the topic space that the application can publish to based on the CN. ACL profiles have the $client-username variable, so restrict the topics based on that, assuming you are using the CN at the client username. See https://docs.solace.com/Overviews/Granting-Clients-Access.htm#Using
You'd then have a topic space that looked something like:
$client_username/some/topicYour receiving application can then be sure that by reading the topic they get a non-spoofed client-username.
1
