anchor.diff:  [source,bash]
   ----
   curl -v \
  --u cs:cs123 \
  --H "X-Killbill-ApiKey: bob" \
  --H "X-Killbill-ApiSecret: lazar" \
  --H "Content-Type: application/json" \
  --H "X-Killbill-CreatedBy: demo" \
  --X POST \
  ---data-binary '{"amount":"12.4"}' \
  -"http://127.0.0.1:8080/1.0/kb/invoicePayments/288983f2-5143-47e4-b967-b8962fc699d1/refunds"
  -----
  -
  -
  -= KAUI
  +     -u cs:cs123 \
  +     -H "X-Killbill-ApiKey: bob" \
  +     -H "X-Killbill-ApiSecret: lazar" \
  +     -H "Content-Type: application/json" \
  +     -H "X-Killbill-CreatedBy: demo" \
  +     -X POST \
  +     --data-binary '{"amount":"12.4"}' \
  +     "http://127.0.0.1:8080/1.0/kb/invoicePayments/288983f2-5143-47e4-b967-b8962fc699d1/refunds"
  +----
  +
  +=== LDAP configuration
  +
  +To enable LDAP, Kill Bill needs to be launched with the following System Properties:
  +
  +```
  +killbill.server.ldap=true
  +# Take a look at your LDAP configuration for the following properties
  +org.killbill.security.ldap.dnSearchTemplate=
  +org.killbill.security.ldap.searchBase=
  +org.killbill.security.ldap.groupSearchFilter=
  +org.killbill.security.ldap.groupNameId=
  +org.killbill.security.ldap.url=
  +org.killbill.security.ldap.disableSSLCheck=
  +org.killbill.security.ldap.systemUsername=
  +org.killbill.security.ldap.systemPassword=
  +org.killbill.security.ldap.authenticationMechanism=
  +org.killbill.security.ldap.permissionsByGroup=
  +```
  +
  +Notes:
  +
  +* If no groups are defined in LDAP, all users will only have read-only permissions
  +* Before an LDAP user can use Kaui, an admin needs to associate his login to the right tenants (see below)
  +
  +
  +== 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].
   
  -== Users
  +=== Users
   
   To configure users allowed to use Kaui, go to `/admin_allowed_users`:
   
  
positive.code: 
  Changing such user (e.g to use `superadmin`), would require editing `shiro.ini` on the Kill Bill side to making sure this initial user can log-in to Kaui (see below).
  
  For a large entreprise solution, an LDAP integration is probably the most flexible. For cases where LDAP is not available, a good middle ground is to rely on a mixed solution between the `shiro.ini` file and the database backend. This is what the rest of this section will describe:
  
  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:
  
  [source,bash]
  ----
  # 
  # Use -Dorg.killbill.security.shiroResourcePath=/var/tmp/shiro.ini to specify your own config
  #
  
  
negative.code: 
  As far as tenant configuration goes, it is possible to create tenants directly from Kaui. If you already have created a tenant in Kill Bill using APIs, you can safely re-create it from Kaui, which will discover it on the server side and simply sync it locally.
  
  === Super user
  
  Kaui has the concept of a super user (*root*) for critical, cross-tenants, operations. By default, it assumes that the `admin` user is the super user, but you can change this by setting the system property `kaui.root_username` (`KAUI_ROOT_USERNAME` Docker environment variable). The password doesn't need to be specified as it is stored on the server side (`shiro.ini`, etc.).
  
  == Summary
  
  1. User, roles, permissions need to be configured on the server side (`shiro.ini`, database, LDAP, Okta, ...)
  2. Tenants can then be created (using a user whole role's permissions allow such operation)
  