The sso dashboard documentation states that /v2/service_instances/:guid/permissions should be used to control authorization: https://docs.cloudfoundry.org/services/dashboard-sso.html#checking-user-permissions
The documentation for the space auditor role (https://docs.cloudfoundry.org/concepts/roles.html) states that:
Assign this role to people who need to view but not edit the space.
A Space Auditor can:
View the status, number of instances, service bindings, and resource use of each application in the space
The endpoint /v2/service_instances/:guid/permissions, though, returns true for all space roles:
- Developer
- Space Manager
- Auditor
I would expect this endpoint to only return true for SpaceDeveloper. By returning true for all roles, third party services will allow any space role dashboard access (which likely has write operations).
For example, the Pivotal MySQL service specifically calls out that only users with the SpaceDeveloper role will have a manage link for the dashboard: http://docs.pivotal.io/p-mysql/#dashboard - I would expect /v2/service_instances/:guid/permissions to control visibility of manage.
The sso dashboard documentation states that
/v2/service_instances/:guid/permissionsshould be used to control authorization: https://docs.cloudfoundry.org/services/dashboard-sso.html#checking-user-permissionsThe documentation for the space auditor role (https://docs.cloudfoundry.org/concepts/roles.html) states that:
The endpoint
/v2/service_instances/:guid/permissions, though, returns true for all space roles:I would expect this endpoint to only return true for SpaceDeveloper. By returning true for all roles, third party services will allow any space role dashboard access (which likely has write operations).
For example, the Pivotal MySQL service specifically calls out that only users with the SpaceDeveloper role will have a manage link for the dashboard: http://docs.pivotal.io/p-mysql/#dashboard - I would expect
/v2/service_instances/:guid/permissionsto control visibility of manage.