Hi Prashant,
> how does the ranger policy using this attributes written like, context
> functions?
Can you give few example of context functions?
Ranger policies support condition expressions that can access context
attributes like action, clientIPAddress, forwardedAddresses, clusterName,
clusterType - for example:
- REQ.action == 'rmdir'
- REQ.clientIPAddress.startsWith("10.10.2")
- REQ.clusterName == 'prod'
Hope this helps.
Madhan
On 3/6/26, 4:38 PM, "Prashant Singh via dev" <[email protected]
<mailto:[email protected]>> wrote:
I think its fine to capture context and send it to the authorizer for the
AuthZ decision.
I feel like we did something similar for OPA :
https://polaris.incubator.apache.org/in-dev/unreleased/managing-security/external-pdp/opa/#input-document-structure
<https://polaris.incubator.apache.org/in-dev/unreleased/managing-security/external-pdp/opa/#input-document-structure>
Check the context section. I would be supportive to having a dedicated
Session Context object as an input to the AuthZ request, which would allow
us to standardize on more things
as they come up.
I would also be keen to know how Ranger will authorize in this case. For
example, how does the ranger policy using this attributes written like,
context functions?
Best,
Prashant Singh
On Fri, Mar 6, 2026 at 4: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
> > >
> > >
> > >
> >
>
>
>
>
>
