[FEATURE REQUEST] CatalogAdmin should be able to list principal roles
- Dominant language
- Java
- Stars
- 2.1k
- Forks
- 522
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 137
Description
### Is your feature request related to a problem? Please describe.
By default, a principal that has a `catalog_admin` role in a catalog cannot list principal roles using the API. The `catalog_admin`'s responsibility is managing privileges and access to the catalog roles in a catalog. After fixing https://github.com/apache/polaris/issues/359 , the `catalog_admin` has the ability to grant a catalog role to a principal role, but has no ability to see the list of available principal roles. This may be ok for cases where a principal has both the `service_admin` and the `catalog_admin` roles, but if there's an enforced separation, the lack of privilege to list principal roles is a hindrance.
### Describe the solution you'd like
The authorization model typically requires a catalog to be in the scope of a request in order to detect that user has `catalog_admin` on the specified catalog. However, PrincipalRoles are not tied to a catalog, so it's difficult for the current authorization workflow to know if the current user does have admin privilege on any catalog. We can consider a separate API, where the `/principal_roles` endpoint is prefixed by catalog, but that feels cumbersome - especially if the caller is an admin on multiple catalogs.
A more likely solution would be to manage a special PrincipalRole that has limited privileges on PrincipalRoles (and possibly Principals) that a user is automatically added to when granted `catalog_admin`.
### Describe alternatives you've considered
_No response_
### Additional context
_No response_
Contributor guide
Research direction
Start by tracing authorization for the /principal_roles endpoint and the catalog_admin privilege flow described in the issue. Review issue #359 for related behavior. A design decision is needed for how catalog-scoped administrators should be authorized to list principal roles; done means the chosen model supports separated catalog_admin access without weakening unrelated principal-role permissions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, authorization, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100