Alex - thanks for the suggestion to inject RealmContext. Will try and get back if any further clarification is needed.
Dmitri, Ranger policies grant permissions on specific resources to Ranger principals (users/groups/roles - managed in Ranger). Ranger policy model has resources as hierarchies. Following are Ranger resource hierarchies for Polaris: 1. root 2. root/principal 3. root/catalog 4. root/catalog/namespace 5. root/catalog/namespace/table 6. root/catalog/namespace/policy In Polaris, each realm contains its own set of resources. Hence a catalog named sales in realm-1 is different from sales catalog in realm-2. So, realm identifier is necessary to distinguish these two catalogs in Ranger policies. I assume realm-identifier is provided by Polaris admin (i.e., not machine generated, like a guid). This is critical so that the same identifier can be used in Ranger policies to grant permissions. If they are not provided by Polaris admin, then mapping you suggested makes sense. About user identity, let's consider two realms having different authentication configurations - one with LDAP, other wth Keycloak. What would PolarisPrincipal.getName() return for user named user1 in each realm? Will each be unique (perhaps by including realm name) or the same? This is critical for authorizers, as they need to map this value to the names referenced in policies. Thanks, Madhan On 4/9/26, 3:27 PM, "Dmitri Bourlatchkov" <[email protected] <mailto:[email protected]>> wrote: Hi Madhan, +1 to Alex's points (below). I wonder why the realm ID is required inside an Authorizer implementation (I assume it's Ranger in this case). If the plan is to pass it to Ranger as one of the authorization request parameters, making it configurable (mappable) by end users might be preferable to always conveying the exact Polaris Realm ID. Authorization decisions must be based on a particular user's identity. That identity depends on certain realm-specific Authenticator settings. So, it is conceivable that two Polaris realms may share the same user (principal) sets (e.g. authenticate against the same Keycloak realm). In that situation, the admin user might also want to share authZ rules for those Polaris realms. What I'm trying to say is that authZ requests coming from both Polaris realms might need the same "selector" parameter to choose the set of rules on the Ranger side. That "selector" value will then have to be something other than the Polaris realm ID, but it will be derived from the config and/or realm ID on the Polaris side. WDYT? Thanks, Dmitri. On Thu, Apr 9, 2026 at 9:13 AM Alexandre Dutra <[email protected] <mailto:[email protected]>> wrote: > Hi Madhan, > > Right now, I think you need to inject RealmContext into your > PolarisAuthorizerFactory. It's fine to inject a request-scoped bean in > an application-scoped bean, as long as the request scope is active > when the bean is accessed – which will be the case when the create() > method is invoked. > > Thanks, > Alex > > On Thu, Apr 9, 2026 at 3:40 AM Madhan Neethiraj <[email protected] > <mailto:[email protected]>> wrote: > > > > Authorizer instances are created per request with following call to the > registered factory: > > > > > > > > PolarisAuthorizer PolarisAuthorizerFactory.create(RealmConfig config); > > > > > > > > RealmConfig doesn’t have any methods to obtain realm identifier. How > does an authorizer implementation find the realm identifier? Perhaps it’s > the name of the ROOT entity in PolarisResolvedPathWrapper object given to > the authorizer in authorizeOrThrow()? I find this name to be > “root_container” in my tests. > > > > > > > > Thanks, > > > > Madhan > > >
