Open ryandurfey opened 6 years ago
The way we envision roles/capabilities working is like this (some of this work has already been done. i.e. the tables and apis to support part of this)
user has a role, role has N capabilities. capabilities map to API endpoints. for example:
john (a tenant customer) has
so according to this john can create/update/delete delivery services but there's nothing that says to what level. i.e. nothing says "let him create/update delivery services but not update the dscp or geoprovider properties".
that would be taking roles/capabilities to another level which could cause user permission management nightmares imo.
rather, we could create more APIs which serve as a subset of PUT /api/deliveryservices/:id and then assign those apis to john.
This seems like a generalization of #1565
Currently all service configuration fields are accessible in a service configuration but we will want to remove access to certain fields or limit responses for tenant customers.
Remove Access Examples: DSCP Geo DB Provider
Limit Response Examples: Maximum IP addresses in DNS answer (0 means all) - want to limit to some max integer value and not allow "0".