Fuzzy authorization

[guicassolato]

Authorization policies in Authorino are binary in the sense that they evaluate to either GRANTED or DENIED, and atomic in the sense that either ALL policies shall grant access or NO access is granted at all.

This issue is a placeholder to start working on the design of some "fuzzy authorization" in Authorino. The overall idea is that the policies can partially grant access to the requested resource, providing enough information for the response to be filtered ("cropped") to the parts that are authorized, while censoring/removing the ones that are not.

An important use case we want to support here is the one for ABAC Row-Level Security (RLS), a.k.a. the "index page" use case. This is a generic description for all use cases where the desired response to a determined requested URL is a list of records (or list of resources), in which some of the resources associated to each record are authorized for the user, some aren't, and we want to only show the authorized ones.

In terms even more generic, this can apply not only to records but to any partial filtering on the response based on access (e.g. resource attributes, table columns, bits of an UI, etc).

Discussion

Should Authorino filter (mutate) the response?

I wouldn't expect Authorino to do the actual filtering of the response to the user, but simply provide authorization metadata, so another component can do the filtering, including the protected service itself if nothing else.

Implementation paths

OPA provides this kind of fine-grained authorization. Authorino definitely under uses it by just checking the result of the injected allow rule. Changing that could be a way into the implementation of this functionality in Authorino, one in the direction of non-binary authorizaiton policies.

An alternative to be explored could be breaking the atomicity of the authorization policies to defining the final authorization response returned by Authorino. In this case, each authorization policy in an AuthConfig remains binary (i.e., either granting or denying access), however the final authorization response is broken down into the evaluation result from each policy (rather than one single GRANTED/DENIED response).

The second implementation option could be perceived as Authorino moving towards being just a Policy Enforcement Point (PEP), rather than a Policy Decision Point (PDP) as well. It is also more complicated due to concurrency control. Therefore, I believe the implementation option based on OPA's fine-grained evaluation of Rego rules to be more promising. One could write an OPA policy containing a Rego rule allow { true } and multiple other rules whose output values are passed to the application using Authorino Dynamic responses.