Hi,
I have a need to evaluate when a message (command or event) is placed on the queue (I’m using Azure Service Bus) and was wondering whether NServiceBus provides access to the underlying EnqueuedTimeUtc? I could read the Time Sent header, but I’m worried that it can be manipulated, so I hoped it was possible to gain access to the EnqueuedTimeUtc value from Azure Service Bus.
Thanks in advance
Hi
Is there a specific reason you are worried about the header being manipulated? Is that a security-related concern?
The Azure Service Bus transport makes the native message available inside the message processing pipeline via the context object as described here.
The exposed class is ServiceBusReceivedMessage which contains the property you are looking for.
Thank you for the quick response.
It’s for security reasons. We’re using JWT tokens and would like to reuse those for authenticating messages between endpoints. And for that reason we’d like to know when the message was placed on the queue by Azure Service Bus.
For the benefit of other NServiceBus users, can I ask about some details about you usage of the JWT tokens combined with the enqueue times? It sounds interesting but we don’t fully understand it.
Of course, no problem at all.
So currently we use JWT tokens to authorize service-to-service communication (REST APIs). Now we’re moving more towards NServiceBus and would like to reuse those JWT tokens for authorization purposes (“is service A allowed to send a command to service B”). But given the async nature of NServiceBus, the JWT token could expire before being processed by the receiving endpoint. That’s why we’re looking into validating the expiration time of the JWT token against the time the command was placed on the queue, to see if the JWT token was valid at that specific time.
Does NServiceBus come with any kind of authorization framework for commands/events etc.?
@SzymonPobiega Do you know if NServiceBus has a way to handle authorizing commands with tokens? Or isn’t this something that NServiceBus does (if so, why not or what’s the alternative)?
Hi
No, there is no built-in authorization mechanism in NServiceBus. In most scenarios the users rely on the security of the messaging infrastructure with the rationale that if someone got access to the messaging infrastructure, the attacker likely has access to all other components of the system anyway.
The idea sounds very interesting and we are going to look into it, maybe starting by building a sample. My understanding is that the token-based authorization would be useful is the messaging infrastructure is public or shared and for this reasons cannot really be trusted as secure, right?
The authorization logic probably would be best handled in a pipeline behavior so it can be reused across multiple handlers and endpoints.
FYI Mark Klefter did an interesting presentation at NDC Porto about this topic
Daniel