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

Client username (sender id?)

borisbucha
borisbucha Member Posts: 7 ✭
in General Discussions #1

Is there a way to get username of a sender of a message?
As a consumer I want to know the name used to authenticate (basic or gss auth scheme) sender session.
Obviously I dont want sender application to attach this as client can't be trusted so maybe VPN can attach this?

I need this ID for further-more granular application authorization.

Publishing clients are typically desktop clients (per user).

Comments

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 644 admin
    #2

    Hi @borisbucha . I'm a bit confused. What your describing seems to break the publish-subscribe paradigm where publishers and consumers are architecturally decoupled from each other. Unless I'm misunderstanding..?

    From how I read it, you want to have a consumer application somehow figure out the client-username of the publisher of a particular message? But you don't want to include that information inside the message because the consumer can't be trusted? And you want the ID for more granular CONSUMER application authorization??

    I don't know how a consumer would be able to determine this if it wasn't included in the message?

    And if the consuming (?) client can't be trusted, how did it connect to the Solace broker?

    Obviously, the publisher can include it's username inside the message, either in the payload or the header or something. If you need something secure, the publisher could encrypt the payload of the message before attaching it to the message, and your trusted clients could somehow decrypt it with a known key.

    Also note that Solace has publish and subscribe ACLs that can enforce what a particular client can publish on or subscribe to. And further, there is the concept of a Subscription Manager, which can subscribe on-behalf-of (OBO) another client. This way, a consumer app could connect with a full deny-list of subscription topics, and only 1 publish topic which could be a "hello I'm here" type message which the Subscription Manager subscribes to, and then it could perform additional authentication based on something and then add allowed subscriptions for that guy.

    Please provide more info of your use case, or let me know if I'm on the right track. Thanks!

  • TomF
    TomF Member, Employee Posts: 412 Solace Employee
    #3

    Hi @borisbucha, from what you're describing where you don't trust the message sender (I think this could well be a mobile client), I suggest you use a publish ACL making use of the substitution variable feature. This will constrain your application so that it can only publish on topics that include its username. Et voila! you know the client username the message was published on because of the topic it was published on. The username doesn't have to be in the message and cannot be spoofed by the sender.

    What's even better is that you can now route and filter the messages, based on the publishing client name. An example might be load balancing clients or providing them with access to different resources based on their username and perhaps payment level.

    I'm almost certain you'll need to start your security layer with OBO. This is the best way to ensure that an untrusted client is not able to subscribe to anything it shouldn't.

    I hope that helps!
    Tom

  • borisbucha
    borisbucha Member Posts: 7 ✭
    #4

    Thank you @Aaron and @TomF ,

    spot on Tom!

    Solution I am prototyping is to replace HTTP web services integration among backend services as well as desktop clients.
    Specifically for desktop client to web-service case I am dealing with variety of clients (actual users) which I want to profile based on their AD identity. Obviously I cant let client attach client name to message payload as that is easily spoofed.
    Solution with substitution variables makes sense.

    I need to play around with OBOs to better understand how can I leverage this feature.

    Thanks again guys and sorry for clumsy problem description. I am just discovering.

    Boris

  • Tamimi
    Tamimi Member, Administrator, Employee Posts: 541 admin
    #5

    Thanks for sharing your questions and thoughts on the community, @borisbucha ! Would love to hear more about your implementation when you come across a solution, maybe even share it on the tips and tricks section 👀

  • Tamimi
    Tamimi Member, Administrator, Employee Posts: 541 admin
    #6

    Hey @borisbucha ! Following up on this, wondering if you ended up with the OBO solution and if not what design decision did you take for your usecase?

  • borisbucha
    borisbucha Member Posts: 7 ✭
    #7

    Hey @Tamimi , substitution variables do the job for now. I have checked OBO and looks to be a powerful feature which we might leverage in the future.

Categories

This Month's Leaders

This Week's Leaders