[GitHub] [pulsar] Geal opened a new issue #5720: authorize tenant level and namespace level access from the authorization provider

[GitBox <gi...@apache.org>]

Geal opened a new issue #5720: authorize tenant level and namespace level access from the authorization provider
URL: https://github.com/apache/pulsar/issues/5720
 
 
   **Is your feature request related to a problem? Please describe.**
   I am currently writing an authentication provider and an authorization provider, and the authorization API only provides the `isSuperUser` method for admin level usage. There is no way to authorise a client depending on the affected tenant or namespace. In my use case, I want my clients to have their own tenant, and be able to give limited access to some namespaces to their developers.
   
   **Describe the solution you'd like**
   Adding new methods to `AuthorizationProvider`:
   - for tenant level access (different from superuser access: can't create, delete or update a tenant, but manage every namespace under the tenant): `CompletableFuture<Boolean> canManageNamespace(NamespaceName namespaceName, String role, NamespaceOperation operation, AuthenticationDataSource authenticationData)`
     - `NamespaceOperation` is an enum that can be any of the namespace management tasks, like `create`, `delete`, `grant-permissions`, etc. The default implementation could ignore it, but other providers could manage more granular access (like, I can affect subscriptions, but not quotas and affinity). I think some operations should still require superuser access, like `set-clusters`or `unload`?
     - the default implementation would check that either we're a super user, or the role is in the list returned by `tenant.getAdminRoles()`
     - maybe a separate function for `list`, since it would not take a namespace name as argument?
   - for namespace level access: `CompletableFuture<Boolean> canManageTopic(TopicName topic, String role, TopicOperation operation, AuthenticationDataSource authenticationData)`
     - same as tenant level access, `TopicOperation` is an enum listing all the possible operations
     - same as tenant level access, the default provider would ignore the operation argument, and check that either we're a super user, or the role is in the list returned by `tenant.getAdminRoles()`
   
   Add corresponding methods to `PulsarWebResource`. Right now it only has `validateSuperUserAccess` and `validateAdminAccessForTenant`. We must modify `validateAdminAccessForTenant` to add the operation, and add `validateAdminAccessForTopic`
   And the biggest part of the task: go through every usage of `validateSuperUserAccess` and `validateAdminAccessForTenant` and check if they can be replaced with finer grain access
   
   **Describe alternatives you've considered**
   I do not know any alternative way to get more granular admin access authorization
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services