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

Reply via email to