Multi tenancy

RuBAN has scale up and scale out mechanisms, it can be installed on a single server and scales out as needed to be distributed across servers.

In a multi-tenant environment an instance of RuBAN is created for each tenant/end-customer. Users access the same url irrespective of which tenant they belong to, it's the job of the Tenant Manager to associate the authenticated user with the appropriate RuBAN instance. The Authentication Stack is provided by passport.js which supports a vast array of authentication strategies/standards. Once a user is authenticated a cookie is attached to the user's session with the unique ruban tenant id and is redirected to the users RuBAN instance. Subsequent requests from the user bypass the tenant manager and are forwarded to the correct ruban instance by forwarding rules in NGINX, an extremely high-performance web-server/load-balancer. A similar approach is taken to associating messages coming from sensors/smart gateways with the appropriate ruban instance. The shared message bus is the end-point to which all messages from assets are sent, the bus re-routes these messages based on the RuBAN instance associated with that asset. All messages from the edge are stamped with a globally unique id (the serial number of the chassis in the case of cisco smart gateways), these ids are associated with RuBAN tenants during provisioning. To support multi-tenancy data-storage the RuBAN instances use a separate keyspace in the cassandra cluster or a fully independent cluster per-tenant. Typically the one cassandra cluster would server many tenants as a cassandra cluster requires significant investment however certain clients will demand total physical separation of their data from other customers so we have made provision for this in the design.