Hi Madhan, Thanks for the context!
In Polaris each request executes independently of other requests and forms its own request context. Not context data is supposed to be shared between different requests. This naturally maps to the CDI Request Scope in the Quarkus runtime environment. Each request goes through the authentication (AuthN) phase separately, followed by the execution phase, which includes authorization (AuthZ). There's no "logout" per se, the request just ends. I do not think introducing user sessions that span multiple requests is justified at this point. Specifically, it will make distributed processing much harder. In the current request execution model all user information is captured in PolarisPrincipal. A separate PolarisPrincipal object instance is created for each request. Like I mentioned before, current usage of PolarisPrincipal resembles javax.security.auth.Subject more than Principal, but I do not think this distinction is consequential. I propose adding the client IP address information to PolarisPrincipal as optional attributes (cf. getToken()). Thanks, Dmitri. On Tue, Mar 10, 2026 at 9:41 PM Madhan Neethiraj <[email protected]> wrote: > Hi Dmitri, > > I was thinking along a user-login session in typical web applications - > user logs in using credentials (username/password, JWT, Kerberos/Spnego, > SSO), obtains a session cookie, perform actions, followed by a logout. In > such application, a session would capture details like username, > user-groups, user-agent, authN-type, IP-address. Perhaps these are not > applicable for Polaris, especially if credentials are expected in every > request. > > Thanks, > Madhan > > > > > > > On 3/9/26, 9:44 AM, "Dmitri Bourlatchkov" <[email protected] <mailto: > [email protected]>> wrote: > > > 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] > <mailto:[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]> <mailto: > > [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]> > > <mailto:[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 > > > > < > > > 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 > > > > < > > > 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 > > > > < > > > 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]>> <mailto: > > > [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]>> > > > <mailto:[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]>> > > > <mailto:[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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
