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.
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.
The issue with setting the property pragmatically is that it can be spoofed by the producer. The JMSXUserId can only be the username which required authentication that can be controlled.
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.
Hi, is there any progress on this feature? I’m curious if I can use non-spoofable JMSXUserID for authentication, without ACL lists.
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?
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 Sorry, it looks like we sent you the wrong way.Let us guide you back.
You’d then have a topic space that looked something like:
$client_username/some/topic
Your receiving application can then be sure that by reading the topic they get a non-spoofed client-username.