Manifest Groups for Subscriber Access
Probably want to encourage people to own their own groups (eg, uw:domain:middleware.doit.wisc.edu:middleware_admins
) and give you VIEW privilege to it, and then add it to your local "role" group(s) (eg, uw:domain:api.wisc.edu:roles:manifest_api_admins
and uw:domain:api.wisc.edu:roles:netid_login_api_admins
or however they are named).
This will enable effective re-use of groups so that we can have some semblance of RBAC, and it enables you to manage the attributes intermediary group (naming scheme, Entity IDs) without the customer needing to worry about it.
You could also create the groups (eg under uw:domain:api.wisc.edu:roles:
) and give the customers UPDATE privs, which would allow them to either directly add people or to add their own group as appropriate. My only reservation with this strategy would be that it doesn't encourage people to think in "Roles" ("who are Middleware Admins and what rights should they have") and instead encourages them to think in terms of permission lists, resulting in in consistent or conflicting lists ("who should have access to admin the Manifest API?" followed by "who should have access to admin the NetID Login API?")