You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polaris.apache.org by Madhan Neethiraj <ma...@apache.org> on 2026/04/09 01:40:02 UTC
Finding realm identifier in authorization calls
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
Re: Finding realm identifier in authorization calls
Posted by Dmitri Bourlatchkov <di...@apache.org>.
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 <ma...@apache.org> 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" <dimas@apache.org <mailto:
> dimas@apache.org>> 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 <madhan@apache.org
> <ma...@apache.org>> 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" <dimas@apache.org <mailto:
> dimas@apache.org> <mailto:
> > dimas@apache.org <ma...@apache.org>>> 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 <adutra@apache.org
> <ma...@apache.org> <mailto:
> > adutra@apache.org <ma...@apache.org>>> 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 <madhan@apache.org
> <ma...@apache.org>
> > <mailto:madhan@apache.org <ma...@apache.org>>> 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
> > > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
Re: Finding realm identifier in authorization calls
Posted by Yufei Gu <fl...@gmail.com>.
Hi Madhan,
Thanks, this makes sense and aligns well with what I had in mind. Mapping
each Polaris deployment to a dedicated Ranger service feels like a clean
way to disambiguate across instances. This addresses my concern, appreciate
the clarification.
Yufei
On Tue, Apr 14, 2026 at 4:17 PM Madhan Neethiraj <ma...@apache.org> wrote:
> Hi Yufei,
>
> > different Polaris instances acting as separate services
> Ok, this helps to understand the context. Thanks.
>
> In Ranger, policies exist within a service (think of it as a namespace).
> Ranger authorizer is configured to enforce policies in a specific service.
> Different Polaris deployments (like sales, mktg, dev, prod) can be
> configured to enforce policies from a different service in Ranger (like
> sales_polaris, mktg_polaris, dev_polaris, prod_polaris).
>
> The name of the configuration is polaris.authorization.ranger.service-name.
>
> Hope this addresses your question.
>
> Thanks,
> Madhan
>
>
>
>
> On 4/14/26, 7:18 PM, "Yufei Gu" <flyrain000@gmail.com <mailto:
> flyrain000@gmail.com>> wrote:
>
>
> Hi Madhan,
>
>
> Good question. I don’t think Polaris has a strong concept of “service”
> today, at least not in a way explicitly surfaced in authorization calls.
> What I had in mind is closer to a deployment or instance boundary, for
> example, different Polaris instances acting as separate services. In that
> setup, if a Ranger server handles requests from multiple Polaris instances,
> the realm ID alone may not be sufficient to uniquely identify the source
> because the same realm name could exist across instances. You may need an
> additional identifier, such as an instance level or service level context,
> to fully disambiguate.
>
>
> That said, this feels more like a concern on the Ranger side rather than
> something Polaris needs to enforce directly. Just wanted to raise it as a
> potential edge case to keep in mind.
>
>
> Happy to discuss more if this becomes relevant to the design.
>
>
> Yufei
>
>
>
>
> On Tue, Apr 14, 2026 at 12:23 AM Madhan Neethiraj <madhan@apache.org
> <ma...@apache.org>> wrote:
>
>
> > Hi Yufei,
> >
> > Thank you. I haven't come across about services in Polaris. Perhaps this
> > is related to federation? Can you please point to relevant documentation?
> >
> > Thanks,
> > Madhan
> >
> >
> > On 4/14/26, 6:33 AM, "flyrain000@gmail.com <ma...@gmail.com>
> <mailto:flyrain000@gmail.com <ma...@gmail.com>>"
> > <flyrain000@gmail.com <ma...@gmail.com> <mailto:
> flyrain000@gmail.com <ma...@gmail.com>>> wrote:
> >
> >
> > Hi Madhan,
> >
> >
> > I agree that having the realm-id in the resource hierarchies is really
> > helpful. It is especially useful when the external PDP has a unified
> > logic for different realms within a single Polaris instance.
> >
> >
> > As you noted, it is also trivial to ignore the realm-id (using
> > wildcards like '*') when the PDP doesn't need it, or in cases where a
> > Polaris instance only has one realm.
> >
> >
> > I have one question to follow up: how does Ranger distinguish between
> > different Polaris services?
> >
> >
> > Thanks,
> >
> >
> >
> >
> >
>
>
>
>
>
Re: Finding realm identifier in authorization calls
Posted by Madhan Neethiraj <ma...@apache.org>.
Hi Yufei,
> different Polaris instances acting as separate services
Ok, this helps to understand the context. Thanks.
In Ranger, policies exist within a service (think of it as a namespace). Ranger authorizer is configured to enforce policies in a specific service. Different Polaris deployments (like sales, mktg, dev, prod) can be configured to enforce policies from a different service in Ranger (like sales_polaris, mktg_polaris, dev_polaris, prod_polaris).
The name of the configuration is polaris.authorization.ranger.service-name.
Hope this addresses your question.
Thanks,
Madhan
On 4/14/26, 7:18 PM, "Yufei Gu" <flyrain000@gmail.com <ma...@gmail.com>> wrote:
Hi Madhan,
Good question. I don’t think Polaris has a strong concept of “service”
today, at least not in a way explicitly surfaced in authorization calls.
What I had in mind is closer to a deployment or instance boundary, for
example, different Polaris instances acting as separate services. In that
setup, if a Ranger server handles requests from multiple Polaris instances,
the realm ID alone may not be sufficient to uniquely identify the source
because the same realm name could exist across instances. You may need an
additional identifier, such as an instance level or service level context,
to fully disambiguate.
That said, this feels more like a concern on the Ranger side rather than
something Polaris needs to enforce directly. Just wanted to raise it as a
potential edge case to keep in mind.
Happy to discuss more if this becomes relevant to the design.
Yufei
On Tue, Apr 14, 2026 at 12:23 AM Madhan Neethiraj <madhan@apache.org <ma...@apache.org>> wrote:
> Hi Yufei,
>
> Thank you. I haven't come across about services in Polaris. Perhaps this
> is related to federation? Can you please point to relevant documentation?
>
> Thanks,
> Madhan
>
>
> On 4/14/26, 6:33 AM, "flyrain000@gmail.com <ma...@gmail.com> <mailto:flyrain000@gmail.com <ma...@gmail.com>>"
> <flyrain000@gmail.com <ma...@gmail.com> <mailto:flyrain000@gmail.com <ma...@gmail.com>>> wrote:
>
>
> Hi Madhan,
>
>
> I agree that having the realm-id in the resource hierarchies is really
> helpful. It is especially useful when the external PDP has a unified
> logic for different realms within a single Polaris instance.
>
>
> As you noted, it is also trivial to ignore the realm-id (using
> wildcards like '*') when the PDP doesn't need it, or in cases where a
> Polaris instance only has one realm.
>
>
> I have one question to follow up: how does Ranger distinguish between
> different Polaris services?
>
>
> Thanks,
>
>
>
>
>
Re: Finding realm identifier in authorization calls
Posted by Yufei Gu <fl...@gmail.com>.
Hi Madhan,
Good question. I don’t think Polaris has a strong concept of “service”
today, at least not in a way explicitly surfaced in authorization calls.
What I had in mind is closer to a deployment or instance boundary, for
example, different Polaris instances acting as separate services. In that
setup, if a Ranger server handles requests from multiple Polaris instances,
the realm ID alone may not be sufficient to uniquely identify the source
because the same realm name could exist across instances. You may need an
additional identifier, such as an instance level or service level context,
to fully disambiguate.
That said, this feels more like a concern on the Ranger side rather than
something Polaris needs to enforce directly. Just wanted to raise it as a
potential edge case to keep in mind.
Happy to discuss more if this becomes relevant to the design.
Yufei
On Tue, Apr 14, 2026 at 12:23 AM Madhan Neethiraj <ma...@apache.org> wrote:
> Hi Yufei,
>
> Thank you. I haven't come across about services in Polaris. Perhaps this
> is related to federation? Can you please point to relevant documentation?
>
> Thanks,
> Madhan
>
>
> On 4/14/26, 6:33 AM, "flyrain000@gmail.com <ma...@gmail.com>"
> <flyrain000@gmail.com <ma...@gmail.com>> wrote:
>
>
> Hi Madhan,
>
>
> I agree that having the realm-id in the resource hierarchies is really
> helpful. It is especially useful when the external PDP has a unified
> logic for different realms within a single Polaris instance.
>
>
> As you noted, it is also trivial to ignore the realm-id (using
> wildcards like '*') when the PDP doesn't need it, or in cases where a
> Polaris instance only has one realm.
>
>
> I have one question to follow up: how does Ranger distinguish between
> different Polaris services?
>
>
> Thanks,
>
>
>
>
>
Re: Finding realm identifier in authorization calls
Posted by Madhan Neethiraj <ma...@apache.org>.
Hi Yufei,
Thank you. I haven't come across about services in Polaris. Perhaps this is related to federation? Can you please point to relevant documentation?
Thanks,
Madhan
On 4/14/26, 6:33 AM, "flyrain000@gmail.com <ma...@gmail.com>" <flyrain000@gmail.com <ma...@gmail.com>> wrote:
Hi Madhan,
I agree that having the realm-id in the resource hierarchies is really
helpful. It is especially useful when the external PDP has a unified
logic for different realms within a single Polaris instance.
As you noted, it is also trivial to ignore the realm-id (using
wildcards like '*') when the PDP doesn't need it, or in cases where a
Polaris instance only has one realm.
I have one question to follow up: how does Ranger distinguish between
different Polaris services?
Thanks,
Re: Finding realm identifier in authorization calls
Posted by fl...@gmail.com.
Hi Madhan,
I agree that having the realm-id in the resource hierarchies is really
helpful. It is especially useful when the external PDP has a unified
logic for different realms within a single Polaris instance.
As you noted, it is also trivial to ignore the realm-id (using
wildcards like '*') when the PDP doesn't need it, or in cases where a
Polaris instance only has one realm.
I have one question to follow up: how does Ranger distinguish between
different Polaris services?
Thanks,
Re: Finding realm identifier in authorization calls
Posted by Madhan Neethiraj <ma...@apache.org>.
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" <dimas@apache.org <ma...@apache.org>> 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 <madhan@apache.org <ma...@apache.org>> 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" <dimas@apache.org <ma...@apache.org> <mailto:
> dimas@apache.org <ma...@apache.org>>> 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 <adutra@apache.org <ma...@apache.org> <mailto:
> adutra@apache.org <ma...@apache.org>>> 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 <madhan@apache.org <ma...@apache.org>
> <mailto:madhan@apache.org <ma...@apache.org>>> 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
> > >
> >
>
>
>
>
>
Re: Finding realm identifier in authorization calls
Posted by Dmitri Bourlatchkov <di...@apache.org>.
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 <ma...@apache.org> 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" <dimas@apache.org <mailto:
> dimas@apache.org>> 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 <adutra@apache.org <mailto:
> adutra@apache.org>> 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 <madhan@apache.org
> <ma...@apache.org>> 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
> > >
> >
>
>
>
>
>
Re: Finding realm identifier in authorization calls
Posted by Madhan Neethiraj <ma...@apache.org>.
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" <dimas@apache.org <ma...@apache.org>> 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 <adutra@apache.org <ma...@apache.org>> 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 <madhan@apache.org <ma...@apache.org>> 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
> >
>
Re: Finding realm identifier in authorization calls
Posted by Dmitri Bourlatchkov <di...@apache.org>.
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 <ad...@apache.org> 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 <ma...@apache.org> 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
> >
>
Re: Finding realm identifier in authorization calls
Posted by Alexandre Dutra <ad...@apache.org>.
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 <ma...@apache.org> 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
>