Hi All,

Now we have implemented two APIs for managing tenant operations [1];

   1. Tenants API for tenant management
   2. Deployments API for deployment automation

Next, we would need to design how tenant user management, API
authentication, and authorization should be handled. Please refer the below
deployment architecture diagram for this:

[image: Inline image 3]

A tenant would need to follow below steps for setting up a containerized
WSO2 environment:

   1. As the first step, a tenant would signup at the Cloud Management
   Application (CMA) for WSO2 services by providing following information:
      - User information
      - Tenant name
      - Domain name
      - Tenant user store information (optional).
         - Tenants might need to connect to their existing user store or to
         create a new user store in the cloud itself.
      2. Next, the CMA will create a namespace for the tenant in the
   container cluster manager via the Tenants API. Here the tenant name can be
   used as the namespace name.
   3. Then the tenant would subscribe to a WSO2 product via the CMA and the
   CMA will execute a new deployment in the above namespace via the
   Deployments API. This process will make use of the WSO2 product's container
   cluster manager artifacts (example: K8S artifacts) for creating the
   containers and configuring load balancing rules.

In this model, we would need to decide how these APIs need to be secured
and authorization needs to be handled. In the current design, both Tenants
API and Deployments API do not store any data. They just wrap the container
cluster manager API and use labels/properties for managing the deployment
metadata.

   1. AFAIU, the first option would be to let the CMA handle tenant user
   authorization and use a system user/token/mutual authentication between the
   CMA and the Tenants and Deployments APIs.
   2. The second option might be to let Tenants and Deployments APIs manage
   authorization by connecting to the IDP of the CMA.

Appreciate your thoughts on this.

[1] https://github.com/wso2/carbon-multitenancy/tree/move-to-c5

Thanks
Imesh

On Fri, Mar 17, 2017 at 3:41 PM, Imesh Gunaratne <im...@wso2.com> wrote:

> Above changes have now been moved to move-to-c5 branch and refined:
> https://github.com/wso2/carbon-multitenancy/tree/move-to-c5
>
> Thanks
>
> On Tue, Nov 22, 2016 at 2:14 PM, Imesh Gunaratne <im...@wso2.com> wrote:
>
>> Hi Lasantha,
>>
>> Shall we move what you have implemented so far to wso2 multitenancy
>> repository [1]? Maybe we can use a new branch called 5.0.0.
>>
>> [1] https://github.com/wso2/carbon-multitenancy
>>
>> Thanks
>>
>> On Mon, Nov 21, 2016 at 12:53 PM, Lasantha Samarakoon <lasant...@wso2.com
>> > wrote:
>>
>>> Hi all,
>>>
>>> Here is the summary of REST resources available in the above Swagger
>>> definition (For the readability).
>>>
>>> GET /tenants Get all tenants
>>> POST /tenants Add a new tenant
>>> GET /tenants/{name} Get a tenant
>>> DELETE /tenants/{name} Delete a tenant
>>>
>>> Regards,
>>>
>>>
>>> *Lasantha Samarakoon* | Software Engineer
>>> WSO2, Inc.
>>> #20, Palm Grove, Colombo 03, Sri Lanka
>>> Mobile: +94 (71) 214 1576
>>> Email:  lasant...@wso2.com
>>> Web:    www.wso2.com
>>>
>>> lean . enterprise . middleware
>>>
>>> On Mon, Nov 21, 2016 at 9:58 AM, Lahiru Cooray <lahi...@wso2.com> wrote:
>>>
>>>> Few more suggestions to consider..
>>>>
>>>>    - Get all tenants : Don't we need to add limit/offset to support
>>>>    pagination?
>>>>    - Get a tenant by name : Response code 400 can be introduced if the
>>>>    name is invalid
>>>>    - Create new tenant: Response code 400 needed to notify the errors
>>>>    in payload.
>>>>    - Delete tenant: Response code 400 can be introduced if the name is
>>>>    invalid/ Can't we introduced 412 if the preconditions are failed to 
>>>> delete
>>>>    a tenant?
>>>>
>>>>
>>>> On Mon, Nov 21, 2016 at 8:44 AM, Joseph Fonseka <jos...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Lashantha
>>>>>
>>>>> Few corrections according to WSO2 REST API guidelines [1].
>>>>>
>>>>> 1. The POST should return 201 Created response.
>>>>> 2. And as a practice we do not use 500 error codes in API interface.
>>>>> 3. If the tenant is already exist you can send a 400 Bad Rest with
>>>>> error json explaining what went wrong.
>>>>>
>>>>> If you want an example please refer [2] and [3].
>>>>>
>>>>> Best Regards
>>>>> Jo
>>>>>
>>>>>
>>>>>
>>>>> [1] http://wso2.com/whitepapers/wso2-rest-apis-design-guidelines/
>>>>> [2] https://raw.githubusercontent.com/wso2/carbon-apimgt/v6.
>>>>> 0.4/components/apimgt/org.wso2.carbon.apimgt.rest.api.store/
>>>>> src/main/resources/store-api.yaml
>>>>> [3] https://docs.wso2.com/display/AM200/apidocs/store/
>>>>>
>>>>> On Fri, Nov 18, 2016 at 1:27 PM, Dilan Udara Ariyaratne <
>>>>> dil...@wso2.com> wrote:
>>>>>
>>>>>> Hi Lasantha,
>>>>>>
>>>>>> I did go through the list of REST APIs that you have defined in the
>>>>>> swagger doc.
>>>>>> But I have not found any API for doing an update to an existing
>>>>>> tenant as well as deactivation.
>>>>>>
>>>>>> Are we skipping those capabilities found in C4 based multi-tenancy,
>>>>>> here ?
>>>>>>
>>>>>> Regards,
>>>>>> Dilan.
>>>>>>
>>>>>>
>>>>>> *Dilan U. Ariyaratne*
>>>>>> Senior Software Engineer
>>>>>> WSO2 Inc. <http://wso2.com/>
>>>>>> Mobile: +94766405580 <%2B94766405580>
>>>>>> lean . enterprise . middleware
>>>>>>
>>>>>>
>>>>>> On Wed, Nov 16, 2016 at 11:12 AM, Imesh Gunaratne <im...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Tue, Nov 15, 2016 at 5:00 PM, Lasantha Samarakoon <
>>>>>>> lasant...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> We are currently working on implementing multitenancy for Carbon-5
>>>>>>>> based products. In order to implement this we are creating Kubenetes
>>>>>>>> namespaces for each tenant (namespaces provides isolation between 
>>>>>>>> tenants
>>>>>>>> and the same approach has been used by WSO2 cloud as well).
>>>>>>>>
>>>>>>>> In most of the customer use cases, the tenants can be defined at
>>>>>>>> the deployment time, but in order to cater SaaS requirements the 
>>>>>>>> tenants
>>>>>>>> has to be created dynamically. To achieve this we have built a REST API
>>>>>>>> using Microservices[1] (please find the attached Swaggger definition 
>>>>>>>> of the
>>>>>>>> API). This API provides a endpoints for basic CRUD operations on 
>>>>>>>> tenants on
>>>>>>>> Kubenetes cluster.
>>>>>>>>
>>>>>>>
>>>>>>> ​Great work Lasantha! Can you please share the API resource/method
>>>>>>> list in text​
>>>>>>>
>>>>>>> ​format?​
>>>>>>>
>>>>>>>>
>>>>>>>> So in order to proceed with this what are the options to integrate
>>>>>>>> this with the platform? Do we need to implement a UUF component and/or 
>>>>>>>> a
>>>>>>>> CLI as well?
>>>>>>>>
>>>>>>>
>>>>>>> ​May be we can write a bash script first and later move to a CLI/UI.
>>>>>>>
>>>>>>> ​I think we would also need to expose methods for automating the
>>>>>>> deployment process once tenants/namespaces are created. Each WSO2 
>>>>>>> product
>>>>>>> would release required K8S defnitions together with the product 
>>>>>>> releases.
>>>>>>>
>>>>>>> ​Thanks​
>>>>>>>
>>>>>>>>
>>>>>>>> [1] https://github.com/lasanthaS/wso2-carbon5-multitenancy-api
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> *Lasantha Samarakoon* | Software Engineer
>>>>>>>> WSO2, Inc.
>>>>>>>> #20, Palm Grove, Colombo 03, Sri Lanka
>>>>>>>> Mobile: +94 (71) 214 1576
>>>>>>>> Email:  lasant...@wso2.com
>>>>>>>> Web:    www.wso2.com
>>>>>>>>
>>>>>>>> lean . enterprise . middleware
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Imesh Gunaratne*
>>>>>>> Software Architect
>>>>>>> WSO2 Inc: http://wso2.com
>>>>>>> T: +94 11 214 5345 M: +94 77 374 2057
>>>>>>> W: https://medium.com/@imesh TW: @imesh
>>>>>>> lean. enterprise. middleware
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> Architecture@wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> --
>>>>> *Joseph Fonseka*
>>>>> WSO2 Inc.; http://wso2.com
>>>>> lean.enterprise.middleware
>>>>>
>>>>> mobile: +94 772 512 430
>>>>> skype: jpfonseka
>>>>>
>>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Lahiru Cooray*
>>>> Software Engineer
>>>> WSO2, Inc.;http://wso2.com/
>>>> lean.enterprise.middleware
>>>>
>>>> Mobile: +94 715 654154
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Imesh Gunaratne*
>> Software Architect
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057
>> W: https://medium.com/@imesh TW: @imesh
>> lean. enterprise. middleware
>>
>>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>


-- 
*Imesh Gunaratne*
Software Architect
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: https://medium.com/@imesh TW: @imesh
lean. enterprise. middleware
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to