Hi Madhan, Just to clarify the intent behind PolarisSession:
What kind of data would this object contain? What is the scope (start/end) of this session? Thanks, Dmitri. On Fri, Mar 6, 2026 at 9:33 PM Madhan Neethiraj <[email protected]> wrote: > Hi Dmitri, > > 1) AuthZ SPI refactoring is currently in progress (PR #3779), which would > allow introduction of new classes. > > 2) PolarisPrincipal sounds like a reasonable place to store user session > attributes. > > 3) "PolarisSession" would work as well, avoiding suffix "Context" :) > > Thanks, > Madhan > > On 3/6/26, 4:47 PM, "Dmitri Bourlatchkov" <[email protected] <mailto: > [email protected]>> wrote: > > > 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] > <mailto:[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 > < > 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 > < > 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 > < > 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]> <mailto: > > [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]> > > <mailto:[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]> > > <mailto:[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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
