stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gayan Gunarathne <>
Subject Re: Stratos Multi Tenant Management & Isolation [2]
Date Mon, 27 Oct 2014 11:10:30 GMT
Hi Lasindu,

I have added some comments in blue.

On Sun, Oct 26, 2014 at 12:24 AM, Lasindu Charith <> wrote:

> The main purpose of this email is to discuss the design and the
> implementation of new Tenant Management in Stratos 4.1.0. As per the
> previous email in dev-list [Subject: Stratos Tenant awareness] the main
> objective of this implementation is to provide a more granular control over
> tenant spaces and it’s users. This will eventually be one of the first
> steps of the billing and metering feature we are going to introduce in one
> of the future releases.
> Let me continue with the proposed design first.
>    - Stratos core consists of 3 major components/products, SM, AS and CC.
>    Currently CC and AS are not tenant aware and are exposed as services to
>    outside. So there is a vulnerability of exposing them to outside to access
>    without authentication. This issue would become worse if multiple tenants
>    try to access other tenant’s data via the endpoint without authentication.
>    Rather CC and AS should not be accessible to users/tenants via as a soap
>    service and should only be accessible via other servers (SM,AS) or via the
>    super tenant. As the first step we can make the CC and AS admin services
>    and set the authorization action to be only accessible for super tenant(s).
>    By this way other tenant(s) users will not be able to mess around with CC
>    and AS endpoints.
>    - ​Since above 3 components/products will be running in super tenant
>    mode, there should be a way to pass tenant-wise data without loading the
>    particular tenant in each component. Basically this will be done by passing
>    tenantId as a parameter in method calls. For an instance almost all the
>    service methods of CC and AS will contain tenantId as a parameter and who
>    ever calls them should pass the relevant tenantId of the required tenant.
>    - The AS partitions, policies as well as CC data/topology will be
>    persisted in the super tenant’s registry according to the tenantId for each
>    and every tenant. The diagram below provides a sample registry data
>    structure in the super tenant’s registry. One of the major reasons to use
>    the ST registry to persist tenants’ artifacts in the below design is to
>    reduce the cost of loading tenants. In addition this data is usually not
>    sensitive. Data will be persisted with their tenantId and public
>    definitions will be stored separately. The RegistryManagers of both CC and
>    AS will do the registry transactions tenant-wise.
> ​
>    - Cloud controller’s singleton FasterLookupDataHolder will be changed
>    to adapt the tenant-wise data. Some information (data from
>    cloud-controller.xml) from the current FasterLookupDataHolder will be moved
>    to a in-memory CommonDataHolder Object and rest of the CC data will be
>    persisted in tenant-wise FasterLookupDataHolders which will be kept as a
>    map with tenantIds under a singleton FasterLookupDataHolderManager.
>    - One of the Major changes in the design applies to the topology since
>    the topology needs to be tenant-aware as well. So the current
>    TopologyManager needs to keep tenant-wise topologies in a Map. The
>    hierarchical topology locking from grouping will also be applicable to the
>    tenant-wise topologies shown below.
>    - ​The messaging component is going through a change. TenantId will be
>    added to the Event abstract class and should be set via the constructor. So
>    in all the concrete classes which extends the Event class should set the
>    tenantId in the constructor itself before publishing the event. This make
>    all the cartridge instances receive all the events despite of the tenant
>    they belongs to. In the initial implementation we’ll go with this until we
>    can come up with tenant-wise topic/messaging model in future.
> ​
> *Current Issues/Problems*
>    - When CC/AS components starts, do we need to load all the tenant
>    information to the in-memory model from the ST registry?
> As we are maintaining the all the tenant information in the ST mode,IMO we
can consider easy loading when getting the tenant information to the in
memory map.

>    - When sending the Complete topology event what is the better way of
>    doing?
>       - To send a single Event with complete tenentIdToTopology Map
>          - This will be a problem when the topologies are large
>       - To send one event per tenant Topology (tenantId & Tenant’s
>       topology as a message)
>       -            This might be a problem when there are many tenants?
> It is better if we can maintain it in event per tenant Topology. If we
maintain like that what is the problem are we en-counting?

>    - Since if I make a change to any of the above components everything
>    breaks and there is no way of testing it until everything is in place
>    correctly, which is really a hard thing to do. Since we currently do not
>    have integration tests for components (CC/AS) it’s really hard to know what
>    is going wrong. So as Imesh suggested, I’m doing the changes to the CC
>    component & Messaging first and test the CC’s basic functionality via the
>    SOAP endpoint (This will make most of the other components to be not
>    build-able). Then my plan is to test CC with AS and messaging to verify if
>    things work fine. Since almost all the component’s are being affected by
>    this change is there a better way of start implementing/testing the ongoing
>    work?
> Suggestions and comments are highly appreciated.
> Thanks,
> --
> Lasindu Charith
> Software Engineer, WSO2 Inc.
> Mobile: +94714427192
> Web:


Gayan Gunarathne
Technical Lead
WSO2 Inc. (
email  :  | mobile : +94 766819985

View raw message