How-to guide
Control access
Restrict which clients can call which services, and which services can call each other, using groups and method restrictions.
Prerequisites
- Admin access to the middleware
Note
Kiwi Distro is currently in private preview. Interfaces and behaviour described here can change before general availability. Contact Kiwify Labs for access.
Kiwi Distro has two independent authorisation policies. A call from a worker is evaluated only by the first; a call from a client is evaluated only by the second. Neither can widen or narrow the other. See Authorisation model for the rules.
By default nothing is restricted. Configuring any grant turns that target or caller from unrestricted into allow-list only. An empty list always means unrestricted, never "deny everyone".
Service-to-service (who may call this service)#
This is target-centric: the called service says who may call it.
kiwi distro set-allowed-callers --service-id <service-id> --callers <caller-id-1>,<caller-id-2>
kiwi distro get-allowed-callers --service-id <service-id>
# narrow one method further than the service as a whole
kiwi distro set-method-restriction --service-id <service-id> --method chargeCard --callers <caller-id-1>
kiwi distro get-method-restrictions --service-id <service-id>
kiwi distro remove-method-restriction --service-id <service-id> --method chargeCard
A method rule can only narrow. A method-level allow can never override a service-level deny.
Client-to-service (what may this client call)#
This is source-centric: the client's own record lists what it may call, directly or through groups.
# direct grants
kiwi distro set-client-allowed-services --client-id <client-id> --services <service-id-1>,<service-id-2>
# groups: grant once, every member inherits it
kiwi distro create-service-group --name billing-services --services <svc-1>,<svc-2>
kiwi distro create-client-group --name finance-apps
kiwi distro set-client-group-grants --client-group-id <id> --service-groups <service-group-id>
kiwi distro set-client-groups --client-id <client-id> --groups <client-group-id>
A client is allowed if either list is empty (unrestricted), or the target service is in its effective grants: its own direct grants plus every group it belongs to. The reserved group all-services always means every service that exists, and it cannot be edited or deleted.
Clients with the superadmin role can never have the all-services grant removed, so administrators cannot lock themselves out.
Use get-client-allowed-services, get-client-allowed-service-groups and get-client-groups to inspect, and clear any grant by passing an empty list.
What a denied caller sees#
A denied call returns a generic 403 with no detail about the policy, so callers cannot probe it.
Desktop app#
The desktop administration app exposes the same settings: an Authorization card on the Services page (service-to-service) and on the Clients page (client grants), plus screens for Service Groups and Client Groups, using multi-select dropdowns.
Not supported#
- Method-level restrictions for clients; client grants are service-level only.
- Bulk "add many clients to a group". Membership is set from each client.
- Memcached cache adapters for client and group data: a Memcached deployment fails fast at start-up rather than misbehaving. Use the in-memory or Redis cache.
Expected result
- Calls outside the granted scope are rejected with a generic 403