Me, Gayan and Shiro are in the process of coming up with a design to enable tenant wise isolation for artifacts in Stratos. This is by extending the new User Management model (Refer subject: Stratos 4.1.0 User Management and Permission Model) by introducing a tenant-wise separation for registry, messaging and persistence model currently implemented in Stratos 4.0.0. One of the main objectives of this model is to extend the usage of Stratos by introducing billing, throttling and metering concept for tenants/users in the future.
In the current implementation there are two levels of users, super admin and the tenant admin. The super admin is the one who can deploy policies, partitions, cartridges etc, whereas the tenant(admin) can only subscribe to what is already deployed by the super admin. But in the new User model, Super admin has the same set of privileges and tenant admin too can deploy partitions, policies, cartridge definitions etc. and tenant users can only subscribe to the cartridges and view certain artifacts. Below are some of the facts from the user perspective which would be in-effect with the new model. Let us know your concerns as well. - Multi-tenant cartridges can only be deployed by super admin and only tenant admins can subscribe to them. There are several concerns here. If we allow tenant users (users with the new user role) to subscribe to multi-tenant cartridges, it would be difficult to decide on the permissions which we should give to a user in the multi-tenant service(say ESB). IMO we should give tenant admin permissions for who ever subscribes to a MT service. Then the tenant admin can configure a secondary user store to be used with that MT service. - Super Admin can make partitions, policies, cartridge definitions public, which can be used by other tenants. Tenants(admins) cannot make any artifact public, so that other tenants can access. If we are to allow other tenants to deploy public definitions, super admin will lose the control. - Policies, partitions and definitions are persisted in the particular tenant registry and AS, CC will have in memory data structures to hold the artifacts tenant wise. But the real problem comes with the messaging and the topology. We no longer can have unified events to be sent over the MB, which are not tenant aware. Both the messaging and topology needs to be tenant-aware in order for multiple tenants to work independantly. Given below is a high level view of the tenant aware Stratos topology. There are few concerns here. - Whether the event publishers and subscribers should load the tenants and publish/subscribe as the particular tenants or each of them work in Super tenant mode and pass the tenant id with the event. IMO better if we go with the super tenant mode and pass the tenant id with the event. Using this way things will be more simple and will reduce the cost of tenant loading etc. - Do we need to change the topology? Ideally tenant-wise separation would be needed in the topology. But this would be the next step IMO. We could first go with the existing topology and then may be refine it with other changes in-effect. - Event should contain tenant Id and who ever send the event should set the tenantId for that particular tenant. Subscriber should read the tenant ID from the deserialized event and process accordingly based on the tenant ID. - Yes, this makes cartridge agent to deserialize each and every event it receives despite the tenant it belongs to. But this would probably be sufficient for the initial implementation where we could have tenant based topics when we extend it further. There may be aspects which are not addressed in this initial email, but will update while things go along. Do let us know any concerns/suggestions and where things might go wrong etc. New ideas are more than welcome. Thanks, -- *Lasindu Charith* Software Engineer, WSO2 Inc. Mobile: +94714427192 Web: blog.lasindu.com
