Hi Madhan, Re: PolarisSessionContext:
1) Using a new class will require Authorizer SPI changes. I'm not sure it is worth the effort for this particular feature. 2) PolarisPrincipal, despite the name, effectively already acts as a "Subject" from the AuthN/Z perspective. The "subject" acpects of PolarisPrincipal are, for example, that it contains "effective" roles for the request, it contains the user's access token (credential). Note that PolarisPrincipal is very different from PrincipalEntity. The former spans all AuthN/Z implementations, while the latter is relevant only to the "native" Polaris RBAC. It may be time to rename PolarisPrincipal to better match its actual purpose, but I do believe it is the best fit for holding the client's IP address (among other attributes). 3) I personally do not like using the word "context" in Polaris class names. A lot of data in Polaris is contextual in nature. I'd like class names to represent the data they contain, rather than the context in which the data is used. Polaris leverages CDI, which implicitly handles request contexts and injects the right objects for each request. This is just my personal opinion on this matter. Subject to discussion, of course :) Cheers, Dmitri. On Fri, Mar 6, 2026 at 7:25 PM Madhan Neethiraj <[email protected]> wrote: > Hi Dmitri, > > Agree on authN layer populating client attributes. I suggest using a new > class, like PolarisSessionContext, to capture all attributes of a user > session and make them available in authZ SPI. Like use of HiveAuthzContext > (1) and HiveAuthorizer (2) in HMS & HiveServer2. I guess Yufei suggests a > similar approach. > > Proxies between the client and Polaris can be handled by including > following 2 attributes in the context: > - remoteIpAddress: remote address of the connection. This can be > address of a proxy. > - forwardedAddresses: value of X-Forwarded-For header (3) > > Thanks, > Madhan > > 1. > https://github.com/apache/hive/blob/master/ql/src/java/org/apache/hadoop/hive/ql/security/authorization/plugin/HiveAuthzContext.java > 2. > https://github.com/apache/hive/blob/master/ql/src/java/org/apache/hadoop/hive/ql/security/authorization/plugin/HiveAuthorizer.java#L163 > 3. > https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For > > > On 3/6/26, 1:45 PM, "Yufei Gu" <[email protected] <mailto: > [email protected]>> wrote: > > > Hi Madhan, > > > It seems naturally fit into ABAC. We might need a holistic approach to how > Polaris supports it. A rough idea about the ABAC style structure would be > something like: > > > AuthorizationContext > Principal > Securable > Operation > request_attributes > client_ip > auth_type > headers > > > Yufei > > > > > On Fri, Mar 6, 2026 at 12:34 PM Dmitri Bourlatchkov <[email protected] > <mailto:[email protected]>> > wrote: > > > > Hi Madhan, > > > > This is a very interesting use case! > > > > From my POV the authentication (AuthN) layer should be responsible for > > obtaining trustworthy attributes about the request. The authorization > layer > > (AuthZ) can then consider those attributes. > > > > Currently, PolarisPrincipal looks like the closest fit for a container of > > client IP addresses because it represents the Polaris client as an > "actor", > > and the IP address is an attribute of the client. > > > > Please have a look at the existing AuthN code in Polaris and see if the > IP > > address can be obtained. I believe it will require some interaction > > with the Quarkus framework. > > > > We should also consider reverse proxies that may exist between Polaris > and > > the client. > > > > Cheers, > > Dmitri. > > > > > > On Fri, Mar 6, 2026 at 3:20 PM Madhan Neethiraj <[email protected] > <mailto:[email protected]>> wrote: > > > > > Hello, > > > > > > To support IP-address based authorization i.e., to restrict access to > > > resources/operations based on IP-address of the client, the context > sent > > to > > > authorizer should include client's IP-address or APIs should be > available > > > to > > > obtain this information. > > > > > > In addition to IP-address, other details of the client can be useful in > > the > > > authorization context - like authentication type. > > > > > > Would appreciate any pointers to get list of client attributes > available > > in > > > Polaris, especially for an authorizer implementation. > > > > > > Thanks, > > > Madhan > > > > > > > > > > > > > > > >
