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 <[email protected]> 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, "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>> 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, > > > > >
