Message Sender Identity

arm Member Posts: 15

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


  • arm
    arm Member Posts: 15

    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.

  • marc
    marc Member, Administrator, Moderator, Employee Posts: 877 admin

    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.

  • Artem_B
    Artem_B Member Posts: 1

    Hi, is there any progress on this feature? I'm curious if I can use non-spoofable JMSXUserID for authentication, without ACL lists.

  • marc
    marc Member, Administrator, Moderator, Employee Posts: 877 admin

    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?

  • TomF
    TomF Member, Employee Posts: 400 Solace Employee

    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

    You'd then have a topic space that looked something like:

    Your receiving application can then be sure that by reading the topic they get a non-spoofed client-username.