anchor.diff:  -H "Content-Type: application/json" \
   -X POST \
   --data-binary '{ "username": "cs", "password": "cs123", "roles": ["customer_support"] }' \
  -'http://192.168.99.100:8080/1.0/kb/security/users'
  +'http://127.0.0.1:8080/1.0/kb/security/users'
   ----
   
   
  -Note: We specified for each request a `api_key` and `api_secret` (any valid tenant key would work). See https://github.com/killbill/killbill/issues/462[Issue 462].
  +Note: We specified for each request an `api_key` and `api_secret` (any valid tenant key would work). See https://github.com/killbill/killbill/issues/462[Issue 462].
   
   
   == Tenant Configuration
  
positive.code: -H "Content-Type: application/json" \
  -X POST \
  --data-binary '{ "role": "customer_support", "permissions": ["account:create", "account:update", "entitlement:change_plan", "entitlement:pause_resume", "entitlement:cancel", "entitlement:transfer", "invoice:credit", "invoice:item_adjust", "tag:create_tag_definition", "tag:delete_tag_definition", "tag:add", "tag:delete"] }' \
  'http://192.168.99.100:8080/1.0/kb/security/roles'
  ----
  
  Let's create a `cs` username that will have only one role `customer_support`:
  
negative.code: 
  == Play Time...
  
  Assuming our `cs` user knows about the `api_key` and `api_secret` of the tenant, he should now be able to make any api calls against that tenant (with the limitation of his permission set).
  
  So for instance, creating a new account in that tenant would work because his role `customer_support` includes the permission `account:create`:
  
  