We currently have a platform with a SOA architecture in which the user's identity is propagated from the web application via middle tier services (REST and SOAP) until we actually query our data storage layer.
We use the user's identity to apply access control at the entity layer. The user's identity is communicated between services by attaching security tokens to the service invocations (SAML/JWT).
One of our customers wants to use an Event Driven Architecture to build a product on our platform instead of the more traditional request/response pattern. They want to use the Azure Service Bus Queues and Topics to achieve a higher scalability.
I was wondering how in this architecture we could propagate the user's identity to the consumers of the messages/events stored on the service bus.
Suppose the user creates a new task in the front-end web application. Instead of calling the Task service (sending along the user's identity) and waiting for the response, the application stores the task creation event in the queue and delegates the actual creation of the task to a background worker subscribed to this type of message.
However, in order to determine if the user who initiated the task creation is allowed to create a task, the task service (a background worker) needs to call the entity layer in the context of the user.
I could store the security token together with the task creation payload, but given the temporal decoupling of the producer and consumer, this token may have expired by the time it is used to call into the entity layer.
Are there any well-established patterns to solve this problem? I realize that I can move the access control into the web-application, but as we've built a platform for others to build applications on, I do not necessarily want to trust those application to enforce the security requirements. That is the key reason why we've build the access control into the entity layer.
Are all consumers of service bus events always part of a trusted subsystem, or are there ways of solving this elegantly?