Hi Madhan, Great question. This is exactly the boundary we’re trying to make explicit in the current authorization refactor work.
Short answer: for external PDP-backed authorizers (Ranger/OPA/etc.), my thought is that PRINCIPAL_ROLE / CATALOG_ROLE admin flows should be treated as Polaris-native RBAC admin operations and denied by default, rather than requiring each external authorizer to implement Polaris RBAC semantics. Concretely, to answer your questions: 1) Should an implementation ignore such operations by failing them? This might be okay if Polaris core doesn’t have any dependency on these operations. - IMHO fail/deny is the expected behavior for Polaris-native RBAC admin operations with external authorizers. There is currently work in progress to update the OpaPolarisAuthorizer to align with this expectation. 2) If implementations are expected to authorize these operations, are they expected to manage the resulting metadata updates as well (like create/drop/list of principal roles/catalog roles/grants/revokes) as well? Or would Polaris maintain the metadata updates? If Polaris maintains the metadata, are all implementations expected to honor the grants/revokes stored in this metadata? - I think the external authorizers should deny these operations, and just ignore existing metadata. There is currently work in progress to update the OpaPolarisAuthorizer to align with this expectation, which may be of interest to you. We’re documenting and implementing this direction in: - RFC: https://docs.google.com/document/d/1OaiQG_C4-yUe0ihaDBxtw_mEcOOzUBnWPazzVbjQi5U/edit?tab=t.0#heading=h.dyow25dt9w1 - Parent tracking issue : https://github.com/apache/polaris/issues/3779 That work introduces clearer intent-based SPI behavior and makes it explicit that different PolarisAuthorizer implementations can avoid native RBAC dependencies in the Polaris call paths. Cheers, Sung On 2026/03/02 03:28:06 Madhan Neethiraj wrote: > Hello, > > > > As suggested in PR #274, all authorizer implementations are expected to > handle all operations in PolarisAuthorizableOperation. However, entity types > PRINCIPAL_ROLE and CATALOG_ROLE are used to manage grants – which seems > specific to Polaris’s default authorization. An authorizer implementation, > like Apache Ranger, will manage grants in its own policy model, hence may not > require/support grants managed via PRINCIPAL_ROLE and CATALOG_ROLE. > > > > Given this, I am looking for guidance on how an authorizer implementation > should handle such operations. > > > > 1) Should an implementation ignore such operations by failing them? This > might be okay if Polaris core doesn’t have any dependency on these operations. > > > > 2) If implementations are expected to authorize these operations, are they > expected to manage the resulting metadata updates as well (like > create/drop/list of principal roles/catalog roles/grants/revokes) as well? Or > would Polaris maintain the metadata updates? If Polaris maintains the > metadata, are all implementations expected to honor the grants/revokes stored > in this metadata? > > > > Thanks, > > Madhan > > > > > > > >
