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]> 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]>> 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 > > > > > > > > > >
