Tenant Support in WSO2 Message Broker 3.0.0

1 Comments

What is Multitenancy



Multitenancy refers to a software architecture in which a single instance of a software runs on a server and serves multiple tenants. A tenant is a group of users who share a common access with specific privileges to the software instance. With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance including its data, configuration, user management, tenant individual functionality and non-functional properties.


What does is means for a Message Broker

When a message broker is considered, the services it offers to the clients are queueing, subscriptions, messaging configurations, message recovery, flow control of messages, QOS levels and many more. In a multi-tenanted broker these services should be able to be served to group of users (tenants) with transparency to each other. One set of users (a tenant), does not need to know even the other exists. Ideally, a tenant should be able to configure messaging properties and configurations in its way without affecting the other. Most importantly, authentication and authorization to the resources should be made into the model so that no cross tenant operations are ever possible. 


Multitenancy in MB 3.0.0 and Limitations

WSO2 Message Broker 3.0.0 is designed on top of award winning middleware platform called "WSO2 Carbon". It has rich multi-tenant features built in. They are inherited to the MB product. More specifically, following resources in MB are multi-tenanted

  1. Queues
  2. Topics
  3. Subscription model
  4. Dead letter channels (message recovery)
  5. All web interfaces 
Above multi-tenancy features are applied irrespective of the messaging protocol you use (AMQP/MQTT). Moreover, it has a tight authentication model bound to carbon authentication to validate users. 

Creating tenants in WSO2 MB

Login to WSO2 MB with a super-tenant user. It comes with a default 

username - admin
password- admin

Navigate to Configure menu and register a tenant. Here a tenant called "a.com" with be created with a user "hasitha" who is the tenant admin. 



Similarly, create another tenant with "b.com" with a user called "ramith". 


With above setup we can explore how multi-tenancy work in WSO2 MB. An important thing to notice here is "admin" user is a user. Following is a short description on how multi-tenancy works in WSO2 Message Broker in above five segments of resources and operations. 

Queues

  • Log into MB with a.com user (username - hasitha@a.com password - ). Create a queue with name "myQueue" navigating to queues >> add in main menu. 
  • It will bare a name "a.com/myQueue". As "/" considered as a special character you cannot use "/" for actual queue names. You can only use alpha-numeric. 
  • Thus WSO2 MB prefixes the queue name with domain name when creating a queue with a tenant user. For super tenant queues it does not add any prefix. 

  •  Logout from a.com user and login back with b.com user. Create the same queue "myQueue". It will be shown like below. 
  • Note that queue created in a.com is not displayed to b.com. Internally, for MB these are individual queues made for tenants. They operate independently. 


How to make subscriptions to tenant queues

  • To make a subscription to a.com/myQueue queue use following connection url in jndi.properties file you use. Note my password is also "hasitha" for tenant user "hasitha" of "a.com". You can navigate to subscription view and see the subscriber from that tenant. 
connectionfactory.QueueConnectionFactory = amqp://hasitha!a.com:hasitha@clientID/carbon?failover='roundrobin'&cyclecount='2'&brokerlist='tcp://10.100.1.146:5672?retries='5'&connectdelay='100''

queue.myQueue = a.com/myQueue



  • To make a subscription to b.com/myQueue queue use following connection url in jndi.properties file you use. Note my password is also "ramith" for tenant user "ramith" of "b.com". You can navigate to subscription view and see the subscriber from that tenant. 
connectionfactory.QueueConnectionFactory = amqp://ramith!b.com:ramith@clientID/carbon?failover='roundrobin'&cyclecount='2'&brokerlist='tcp://10.100.1.146:5672?retries='5'&connectdelay='100''

queue.myQueue = b.com/myQueue


  • Above screenshots demonstrates that subscriptions Web Interface also respects multi-tenancy. 

Topics

  • Log into MB from a.com user and create a topic called "myTopic". 
  • Now if you log into b.com user, you will see no topic details of a.com as expected. You can create same topic "myTopic" in b.co domain as well. 
  • Above separation is internally done with "WSO2 Registry". Details of different tenants are kept in different registry spaces. 

How to make subscriptions to tenant topics

  • To make a subscription to a.com/myTopic topic use following connection url in jndi.properties file you use. Note my password is also "hasitha" for tenant user "hasitha" of "a.com". You can navigate to subscription view and see the subscriber from that tenant. 

connectionfactory.TopicConnectionFactory = amqp://hasitha!a.com:hasitha@clientID/carbon?failover='roundrobin'&cyclecount='2'&brokerlist='tcp://192.168.0.100:5672?retries='5'&connectdelay='100''

topic.myTopic = a.com/myTopic




  • If you click on "myTopic" in topic tree and view details, that subscriber will be displayed. 


  • Thus when you create a topic even if tenant domain prefix is not displayed there, to connect to that topic, you need to prefix it by  "[Tenant_domain/]".  Unlike queues, topic is not an existing thing in broker. It is defined according to topic subscribers. 
          In following example, let us create a new tenant called c.com and create a topic subscription using following connection url in jndi.properties. 

connectionfactory.TopicConnectionFactory = amqp://isuru!c.com:isuru@clientID/carbon?failover='roundrobin'&cyclecount='2'&brokerlist='tcp://192.168.0.100:5672?retries='5'&connectdelay='100''

topic.myTopic = c.com/myTopic


       Notice that in UI, topic is created automatically in UI's topic tree. 

Security Model Across Tenants


  • In above queue scenario, if tenant "a.com" knows that tenant b exists, even then it has to know a valid username and password of a user of a.com that has access to queue a.com/myQueue. It cannot use any user name/password of its tenant to connect to it. 

Dead Letter Channel


Dead letter channel is a queue where messages that were failed to deliver by broker routed to. This queue is also defined per tenant. Failed messages of queues of a.com will be routed to DLC queue of "a.com/DeadLetterChannel". 



Thus, in WSO2 Message broker, all necessary resources and operations are multi-tenanted. Conclusion is that WSO2 MB is a multi-tenanted broker that can work as a cluster of broker nodes too. You can balance the load coming from different tenants across nodes...!!

Hasitha Hiranya

1 comment:

Instagram