Identity propagation using Azure service bus

Question

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.

FOR EXAMPLE:

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?

Answer 1

There are commonly two identity roles in play when you use middleware for routing messages. One identity role is about the relationship between senders/receivers and the middleware, the other is about the end-to-end relationship between the producer of the message and the ultimate consumer of the message.

The identity used in these two roles can be the same, but it also can be different and often is.

For Service Bus, we chose a token-based model for access control that allows a trusted subsystem approach and concrete identities to be used for the sender/receiver to middlware relationship with the same model. The shared access token can be directly generated by the client when in possesion of the shared key. That's how our token providers work with connection strings. You can also generate those tokens externally in a simple STS (using the token provider or https://brentdacodemonkey.wordpress.com/2015/02/21/sas-its-just-another-token/) and trade them against some end-user identity proof, and pass the token on to the shared access token provider.

For the end-to-end relationship between producer and consumer, we leave the door open for whatever is appropriate for the use-case. We stay out of and don't interpret the payload body and thus allow that to be signed and encrypted. You can flow tokens and key-hints in the message properties. You can flow long-lived tokens (including JWTs from Azure Active Directory) in properties or payload, or you can use X.509 certs to authenticate and protect the end-to-end payload. JWE is a fresh standard for payload-level security https://www.rfc-editor.org/rfc/rfc7516