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:
[email protected]


With regards,
Apache Git Services

Reply via email to