anchor.diff:  Each request to Kill Bill requires authentication. The authentication phase verifies that the user exists in the system and that its credentials are correct. Once the credentials have been validated, the roles associated to the user are then extracted, and then the set of permissions associated to each role are also retrieved. The credentials are passed in the request using http basic authentication mechanism. Kill Bill relies on http://shiro.apache.org/[shiro] for the backend implementation.
   
   
  -Note that the authentication/authorization is orthogonal to the tenant access: The set of permissions associated to a given user is the same for all tenants (for which he has the keys). So, a potential superuser with all the permissions and with access to the `api_key`/`api_secret` for all tenants would have full control of the entire system. It is common practise to create a cross-tenant admin with the ability to only manage tenants and nothing else, and then have one superadmin per tenant,...
  +Note that the authentication/authorization is orthogonal to the tenant access: The set of permissions associated to a given user is the same for all tenants (for which he has the keys). So, a potential superuser with all the permissions and with access to the `api_key`/`api_secret` for all tenants would have full control of the entire system. It is common practise to create a cross-tenant admin with the ability to only manage tenants and nothing else, and then have one superadmin per tenant.
   
   
   = User Management APIs
  
positive.code: = KAUI
  
  
  KAUI has been extended to understand all the user/role/permission management and will manage the corresponding sessions. Some of those implementation details were covered in http://killbill.io/blog/multi-tenancy-authorization[our previous blog post}.
  
  However KAUI does not yet have the flexibility to manage the user/roles/permissions, and also requires making each user known available.
  
  
  == Initial Configuration
  
  However the catch-22 situation described in the previous section to configure the very first user remains true both for killbill and KAUI:
  
  * For killbill server, we already described the initial configuration through the `shiro.ini` file
  * For KAUI, we need to also make that admin account visible (this is a small limitation configuration). Note that the credentials, roles,... associated to that account are entirely managed on the server side (killbill) so there is no duplication or security holes.
  
  In the `kaui` database, insert the initial entry for the `superadmin`:
  ```
  insert into kaui_allowed_users (kb_username, description, created_at, updated_at) values ('superadmin', 'super admin', NOW(), NOW());
  ```
  
  == Adding new Allowed User
  
  Before our new `cs` user can be able to login to KAUI, the `superadmin` must make it visible. The screen `/admin_allowed_users` (the top right icon will bring you there), allows to enter that user. Only the name and a descriuption needs to be entered (and not the credentials/roles which are managed by the backend) need to be entered.
  
  After entering a new user, the UI will allow to select the tenants this user has access to.
  
  
negative.code: 
  Kill Bill offers apis to manage the users/roles/permissions, where new user/roles/permissions will be stored in a database. As described earlier, apis calls require authorization/authentication so there is a catch-22 situation here, hence the mixed approach:
  
  * The `shiro.ini` file is used to configure the initial user (could be a superadmin with all permissions or an admin with just enough permissions to manage the user/roles). For simplicity, we will call it `superadmin` and will assign one role containing all permissions.
  * Once deployed, the 'superadmin' is now able to make api calls to configure new users/roles.
  
  The `shiro.ini` file will look like the following:
  