On Tue, Sep 30, 2014 at 8:24 PM, Lasindu Charith <lasi...@wso2.com> wrote:
> 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 > -- *Lasindu Charith* Software Engineer, WSO2 Inc. Mobile: +94714427192 Web: blog.lasindu.com
