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 > > > > > > >
