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