Message Bus Authorization design

I have compared Message Queuing with the message bus in an earlier article. One of the differences is that the message bus is more concerned about the security of communication, the message bus can control the communication between the two sides, the control of communication is based on the authorization. Therefore, the design of the authorization model is a problem that the message bus must consider. The so-called authorization, is to verify that the communication between the two parties have established a credible communication relationship. In this article we will talk about the design of the message bus permissions.

Introduction to message bus usage scenarios and RABBITMQ communication

Before introducing the licensing design, let's take a look at some of the necessary information. Typically we apply the message bus to these scenarios:

1. Buffer Class-Self-production self-consumption
   
2. Decoupling class, asynchronous class--producer consumer model
   
3. Service invocation Class (RPC)--Request/response
   
4. Control Coordination Class--publish/Subscribe
   
5. Notification class--broadcast
   

RABBITMQ original communication mechanism is very simple: publish (send), consume (receive). Other models are constructed on this basis. So we can divide the API of communication into two categories:

• Publish (Sender): Just need to know Exchange,routingkey
  
• Consume (receiver): Need to know Queue,routingkey
  

In other words, as a simple sender, it is not necessary to queue.

The Requester app establishes an association with the communication queue

In fact, the so-called authorization, corresponding to the database model is the establishment of communication between the database records of the relationship between the two. When establishing a relationship, the receiving party must create the relationship with Queueid as the queue primary key. And the sending party? If, as assumed above, it does not require a queue, it can only be created with AppID as a relationship. This type of authorization is also common, such as when a service is requested to invoke a service, an AppID is applied to the service management console to invoke the service. But this way of establishing the relationship, the authorization of the message bus encountered the following two aspects of the problem.

Multiple identity issues

The first scenario is a buffer class scenario, and many messages are self-produced from consumption. For this scenario, you only need to rely on one queue in the application, without communicating with the external application, and the second scenario is a stage or component under the Pipeline-filter model. Shown

It receives intermediate results from the previous stage, finishes processing the data, and then sends the latest intermediate results to the next stage.

In both cases, the sender must have a queue.

Problems with the Request/response model

For Web services, a single invocation is a request/response model from the communication model. But this communication relies on the HTTP protocol, and RABBITMQ's consumption is based on queues (the advantage of queuing is that buffering, asynchrony, decoupling of these features are antagonistic to blocking waits). In this case, we are going to simulate the Request/response model based on RABBITMQ (note that this is not to violate the intent of the queue, but to simplify communication for a particular business scenario), you must rely on a queue that receives the response response. So this model is destined to have a queue on the request side as well. Of course, you might think that if the queue is destroyed immediately after receiving the response message based on a queue that is temporarily generated, it is just as possible with the stateless feature of HTTP. I'm not thinking about this, but it depends on how often the Request/response model is used, and if the frequency is low, it can be received, but if it's very frequent, the cost of creating a queue is far greater than the cost of maintaining a fixed queue.

Virtual queues

It appears that assigning a queue to the sender is a more viable solution. But for the simple sender, the allocation queue causes the waste of the message server resources, because from the communication point of view, there is no need for a real queue, and here it exists to fit the peer authorization model. Therefore, we can choose a compromise solution-for the simple sender, the virtual queue instead of the real queue.

When an app requests a queue, we divide it into three categories: the simple sender, the simple receiver, both the sender and the receiver. Only the latter will create a real queue on the Rabbitmqserver, and the simple sender will not create a real queue on rabbitmqserver, only create a queue record for it in the database. The following queue we talk about is either a real queue or a virtual queue. Each queue is assigned a secret that uniquely globally identifies the queue, and from a security standpoint, the secret of the queue is only known to the requester itself and the console.

Queues are isolated by communication model

When a queue is created, it must choose whether it is a sender or a receiver or both, and what type of communication it is. Only the type of communication is specified so that it is properly bound to the appropriate exchange. In addition, the two queues of communication can only be in the same model, for example, Produce/response or request/consume these cross-communication models can never be seen.

This isolation is both a technical constraint and a semantic constraint.

Authorization implementation

Some of the prerequisites and reasons for the design are discussed. Let's talk about how we're going to implement the authorization. The mandate is mainly divided into the following three aspects.

Queue Request

First, the one step that must be experienced is to approve the queue request. That is, if an application is to communicate with another queue, it must request a queue, and then the manager of the console needs to audit it. In fact, the audit is mainly for publish and broadcast. Because of the two sets of point-to-point communication models, Produce/consume and request/response, their communication needs to undergo an audit of establishing a connection. Broadcast,publish, as a public or semi-public service, does not need to be authorized when they send messages.

Channel

Depending on the communication model, we have a different relationship with the sender and receiver. For the two models of Produce/consume and Request/response, a point-to-point communication link is created, which we call the channel (Sink).

A channel is a one-way link, based on the source queue and the destination queue. There is a principle about the receiver: because each receiver can only consume messages from its own queue, we mainly control the sending permission from the sender to the receiver, which is the same as the HTTP request, and usually you only have the server verify that the initiator is trustworthy.

The Channel console shows:

For communication under this model, the sender needs to hold:

1. Identity of the self queue: Secret
   
2. Name of the destination queue: Targetqueuename (the name is publicly exposed by default)
   
3. Token acquired after channel authorization
   

The receiver only needs to hold the identity of its own queue: Secret can consume its own queue.
Here is a special place, that is, the self-production self-consumption model of the buffer scene. This scenario is only around a queue of communication, this situation is a special case of the channel, we can learn from TCP/IP processing "loopback address" (loopbackip,127.0.0.1, means to represent the local machine, from the network card on the back, do not need to go around the network) in the way: when requesting a queue , you must apply for the Produce-consume model (that is, both production and consumption of the queue), and then secret with the same token to indicate its particularity, Targetqueuename fill in the public name of the queue itself.
Channel for the Publish/subscribe model, a one-to-many relationship is created, which we call channel. Based on some considerations, we have implemented the Publish/subscribe as a precision delivery model, and for another implementation, I've seen a previous post. The authorization here is to generate a pub/sub relationship for the recipient's authorization. Channels in the console UI display:

Based on this model of communication, the sender (publish) only needs to hold: the identity of its own queue: Secret. Authorization is reflected in the process of finding subscribers to be sent when publish.

Subscribers only need to hold the identity of their own queue: secret, which can consume messages from the sender of their own subscriptions.
The above is the message bus permissions design, in general, the queue-to-queue-based peer authorization model. Code implementation SEE: Https://github.com/yanghua/banyan

Message Bus Authorization design