Hi Madhan, Good point about using wildcards for realms in Ranger policies! I was not aware of that.
Cheers, Dmitri. On Mon, Apr 13, 2026 at 5:57 AM Madhan Neethiraj <[email protected]> wrote: > Hi Dmitri, > > > by adding a configuration flag or some other property to control whether > > the realm ID is included in Ranger requests. > > > An authorizer instance is created for each request in Polaris and is tied > to a specific realm. An option to exclude realm identifier from > authorization calls (to Ranger) may not be helpful, especially considering > audit logs generated by Ranger authorizer needs to capture enough details > to identity the accessed resource. In addition, supporting 2 models of in > Ranger policies (one with realm identifier and other without) would add > unnecessary complexity to policy authors. I suggest retaining realm > identifier in resource names sent to Ranger authorizer. > > > simple (single realm) deployments can enjoy simpler setup (no > > realm ID since it's effectively irrelevant > > > Note that Ranger policy authors can use wildcard ('*') to effectively > ignore the realm identifier and grant access to specific resource names > across any realm. > > Thanks, > Madhan > > > > > On 4/11/26, 2:42 AM, "Dmitri Bourlatchkov" <[email protected] <mailto: > [email protected]>> wrote: > > > Hi Madhan, > > > Good point about resource identification. Ultimately, I guess it relates to > how the (Ranger) Authorizer is intended to be used: whether it is > multi-realm or whether the realm is implicit. > > > As far as I know this distinction is not well documented in current Polaris > materials. Current documentation effectively treats the realm as implicit > in most cases. > > > Also users operating only one realm generally do not need to worry about > the realm ID (which will default to "POLARIS"). > > > I'd like to propose delegating this concern to the Polaris Administrator by > adding a configuration flag or some other property to control whether the > realm ID is included in Ranger requests. > > > This way simple (single realm) deployments can enjoy simpler setup (no > realm ID since it's effectively irrelevant), while more complex deployments > can choose to include realm IDs. > > > Since in this case realm IDs become part of entity identities, I guess my > earlier comments about a free mapping of realm ID to some Ranger-side > values is not really relevant. Having a simple on/off condition is probably > sufficient. > > > WDYT? > > > Re: realm IDs - Polaris imposes no restrictions on their format, AFAIK. > Ultimately, whoever deploys Polaris controls the format and values of realm > IDs. > > > Re: user identity with multiple authN configurations - each authN domain > will be distinct from others and user names can be reused (without causing > clashes in Polaris). > > > In this respect, the Polaris Administrator configuring Ranger for a > particular realm is responsible for ensuring that authZ rules relate to the > same user domain as the authN settings. > > > Cheers, > Dmitri. > > > On Thu, Apr 9, 2026 at 8:33 PM Madhan Neethiraj <[email protected] > <mailto:[email protected]>> wrote: > > > > 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]> <mailto: > > [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]> <mailto: > > [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]> > > <mailto:[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 > > > > > > > > > > > > > > > > > > > > > >
