anchor.diff:  Of course, for our own purpose of providing the service, we will also create a very first tenant to invoice our merchants (e.g the Shakti business). That tenant will be called `saas` ('Subscription As A Service'), and the associated admin user will be called *admin_saas*.
   
   
  -Also, for sake of simplicity, we will setup Kill Bill to use a static http://shiro.apache.org/configuration.html[Shiro configuration file] to configure the various admin users/roles. In real life, it would be more practical to rely on LDAP rather that static configuration, which requires restarting Kill Bill when creating new users/roles. The LDAP configuartion is supported by Shiro but we will not describe the steps in that turorial to keep it simple.
  +Also, for sake of simplicity, we will setup Kill Bill to use a static http://shiro.apache.org/configuration.html[Shiro configuration file] to configure the various admin users/roles. In real life, it would be more practical to rely on LDAP rather than static configuration, which requires restarting Kill Bill when creating new users/roles. The LDAP configuration is supported by Shiro but we will not describe the steps in that tutorial to keep it simple.
   
   
   == Kill Bill Multi-tenant Deployment
  
positive.code: 
  === Scenario
  
  In this tutorial, we will look at how one could leverage the multi-tenancy feature from Kill Bill. The scenario we will describe, is one where we would like to provide 'Subscription As A Service' (SaaS) in the cloud (AWS). The tutorial will skip all the operational good practises such as redundancy of instances, firewalls, load balancers and focus instead on the Kill Bill specifics. Also, note that when deployiong in the cloud where instances can come and go, the https://github.com/killbill/killbill/wiki/Kill-Bill-Notification-Configuration[configuration of the bus and notifications queues] need to be understood.
  
  
  We will assume that we only need one plugin to make the payments, and as an example we will use the stripe plugin.
  
  
  === Users and Roles
  
  Let's start be defining some users and role:
  
  * The user setting up the `Subscription As A Service` in the cloud, is called *superadmin*, and will have all the privileges to configure the tenants and setup the roles associated with the other users.
  * The admin user associated to each tenant will be called `admin_X` where `X` is the name of the tenant.
  
negative.code: * API Secret: `some_secret_for_shakti`
  * Click on the `Create tenant` to also create the tenant in Kill Bill.
  
  At this point, the tenant exists in Kill Bill and is known from KAUI as well.
  
  We can then configure the allowed users. KAUI needs to know who can access which tenant, and this information is kept in the KAUI database.
  It really means that any user known from Kill Bill (shiro.ini) will be able to make API calls against any tenant provided the user specifies the correct tenant `api_key` and `api_secret`, so the security resides behind keeping those keys secret.
  