Bulk authorize multiple requests in a single OPA call

[robhafner]

We currently define rego rules and input in the following format to perform authorization for our REST API.

Rules:

allow if {
  not deny
  grant
}

grant if {
  input.request.permission in ["update", "add", "delete", "create", "remove", "secure"]
  regex.match(`^/types((\/){0,1}$|(\/.+)){0,1}`, input.request.uri)
  some group in claims.authorities
  group = "app"
}

...

Input:

{
    "request": 
        {
    		"permission" : "read",
        	"uri" : "/types/types"
    	}
    ,
    "token" : "<oauth-token>"
}

Response:

{
  "allow" : "true"
}

We would also like to be able to bulk authorize an array of requests (i.e permission & uri) using the existing rego rules and possibly some additional rules in a single call to OPA using the following input:

Input:

{
    "request": [
        {
    		"permission" : "read",
        	"uri" : "/types/types"
    	},
        {
    		"permission" : "update",
        	"uri" : "/types/types"
    	},
       ...
     ]
    ,
    "token" : "<oauth-token>"
}

And receive a response that looks something like the following:

{
    "allowed" : [ {"permission" : "read", "uri" : "/types/types"}],
    "denied" : [{"permission" : "read", "uri" : "/types/types"}]
}

Is this possible in OPA? If so, can you point me to an example that I can refer to?

Thanks in advance!

[charlieegan3]

Something like this perhaps? https://play.openpolicyagent.org/p/JihmhhAuhg

[charlieegan3]

Maybe something like this with the with keyword: https://play.openpolicyagent.org/p/D8XpsgQrLh

[robhafner]

Yes, that is what I was looking for. Thanks for the example!

I have a related question now that this is working. Let me know if you would prefer that I enter this question on a different discussion thread.

In short, all of the requests (i.e permission/uri pairs) are associated to a single JWT. In order to reference the claims in the rego rules, I updated the 'input' to include the token. However, this seems like it may result in the token being verified for each 'request' when it only needs to be verified once. Can you confirm if the token is being verified once per request? Assuming the token is being verified more than once, is there a way optimize the rules, such that for both use cases, the token is only verified once?

Example:
https://play.openpolicyagent.org/p/3hqzWqvxrZ

[charlieegan3]

If you wanted to make sure that authenticated user was only evaluated once, you could instead use with, with some path in data instead like this: https://play.openpolicyagent.org/p/sMLqjirL35

[anderseknert]

The result of calling a built-in function is cached for the duration of the evaluation, so calling it over and over with the same input should not have it verified more than once. Using opa eval with the --profile flag, or even opa bench is a good way to confirm when in doubt.

[robhafner]

Thanks again! Your example was very helpful.

I hadn't considered using the 'data' location as a temporary evaluation area in this manner. Updating the rego rules to refer to 'data.uri' and 'data.permission' still breaks the existing rules for the original input. However, fixing that appears to be relatively simple as I can just add the following snippet.

simple decision

simple_decision contains result if {
g := grant with data.request as input.request
d := deny with data.request as input.request
result := {"grant": g, "deny": d}
}

allow if {
some sd in simple_decision
not sd.deny
sd.grant
}

[robhafner]

I finally got around to tinkering with the profiler and I'm not seeing the results I expected.

For the following policy and input:
https://play.openpolicyagent.org/p/E9L8jTdXDw

The profiler shows lines 17, 18, and 27 being evaluated 20, 30, and 30 times respectively. Also, if I increase the number of items in the input.requests array by 1, the number of evaluations increase to 24, 36, and 36 respectively.

While the input is changing as bulk_decisions iterates over input.requests the token being passed in isn't changing. Is there a way to further optimize the policy so that the number of evaluations for these lines does not increase as the number of items in the input.requests array grows?

profile output:

|   TIME    | NUM EVAL | NUM REDO | NUM GEN EXPR |              LOCATION              |
+-----------+----------+----------+--------------+------------------------------------+
| 2.56104ms | 20       | 20       | 2            | types.rego:17                      |
| 481.003µs | 30       | 30       | 3            | types.rego:18                      |
| 98.748µs  | 30       | 30       | 3            | types.rego:27                      |
| 47.71µs   | 10       | 10       | 2            | types.rego:40                      |
| 45.666µs  | 5        | 5        | 1            | types.rego:54                      |
| 35.542µs  | 10       | 10       | 2            | types.rego:39                      |
| 35µs      | 5        | 5        | 1            | types.rego:41                      |
| 31.957µs  | 3        | 3        | 3            | types.rego:66                      |
| 30.542µs  | 10       | 0        | 2            | types.rego:32                      |
| 30.5µs    | 1        | 1        | 1            | data.sas.types.authz.bulk_decision |
+-----------+----------+----------+--------------+------------------------------------+```

[anderseknert]

Replace the use of with to instead use functions, or otherwise rewrite the policy not to depend on that. with is known to be slow, and should only occasionally be used outside of tests, IMHO. Since with is essentially telling OPA "re-evaluate this code where I might have changed anything in data or input", my guess is simply that it doesn't take into account what you've changed specifically, but does a full re-eval of the rules involved.

[robhafner]

Thanks @anderseknert! I was actually wondering if "with" was more meant for testing purposes.

I finally got around to taking the Open Policy Authoring and OPA Performance online courses from Styra. Great content in both courses and I thought they were very helpful in understanding some features of OPA.

I'll work on creating a function to see if it helps with the number of evaluations.

[anderseknert]

Thanks @robhafner! I'll make sure to pass that on to @ericjkao as he's the genius behind most content in the academy 🙂

[robhafner]

I spent some time attempting to stub out a function. It's not quite working yet as I'm running into the following error and am not sure why the functions is producing multiple outputs.

policy.rego:68: eval_conflict_error: functions must not produce multiple outputs for same inputs

Playground Link:
https://play.openpolicyagent.org/p/R6BySGESPX

Removing the use of "with" seems like it requires the rule definitions to be defined in the function so that the variable used in a rule condition is in scope. Is that a requirement of moving to a function or is there another way that I'm not considering which would avoid that requirement?

[robhafner]

I got the functions to work now. I'll run this through the profiler to see if it changes the number of evaluations of the jwt.

https://play.openpolicyagent.org/p/G2JTHgMJli

[robhafner]

After making a few more tweaks to the policy to add an else clause to ensure the function always returned a defined value I can confirm that the jwt evaluation is being evaluated 2 times regardless of the number of items included in the input.requests array.

https://play.openpolicyagent.org/p/0fiWoEXxOz

|   TIME    | NUM EVAL | NUM REDO | NUM GEN EXPR |              LOCATION              |
+-----------+----------+----------+--------------+------------------------------------+
| 260.083µs | 1        | 1        | 1            | data.sas.types.authz.bulk_decision |
| 246.666µs | 2        | 2        | 2            | types.rego:17                      |
| 38.292µs  | 12       | 12       | 4            | types.rego:75                      |
| 33.79µs   | 3        | 3        | 3            | types.rego:18                      |
| 32.373µs  | 12       | 12       | 4            | types.rego:74                      |
| 28.709µs  | 3        | 3        | 3            | types.rego:86                      |
| 23.209µs  | 4        | 4        | 2            | types.rego:41                      |
| 13.501µs  | 4        | 4        | 2            | types.rego:61                      |
| 11µs      | 4        | 4        | 2            | types.rego:60                      |
| 9.082µs   | 4        | 4        | 2            | types.rego:46                      |
+-----------+----------+----------+--------------+------------------------------------+

Thanks for your help! Much appreciated. I have some work to do now to update our converter code to use the updated policy structure. One more question before I start down that path. Will the new policy structure have any impact on how indexes are used to determine the rules to evaluate or the short circuit logic? Based upon what I've read in the documentation I believe it won't, but thought I should confirm as updating the converter code does take some time.

[anderseknert]

Looks good to me!

[robhafner]

I just noticed that the behavior of using an array of sets is different than what I was expecting. For instance, if two rules defined in the array of sets are evaluated and one of the rules evaluates to true and the other to false it seems OPA returns a value of undefined for the function.

For example, for the following policy if lines 66-71 are included, the value of function_test is undefined. If those lines are commented out, the value of function_test is [true].

https://play.openpolicyagent.org/p/NINPG1WC3i

Is this the correct way to iterate over an array of sets containing rules to receive the same behavior as if the rules were defined outside of the function in the root of policy? The earlier example shared by @charlieegan3 only included a single rule so I am looking to modify the syntax to support multiple rules.

[robhafner]

Given input.folder_hierarchy[_] == "..." is a form of iteration, I went ahead and rewrote the condition using the following composition and confirmed it produces the expected behavior.

{match | some folder in input.folder_hierarchy; match := folder == "07370482-f15c-4ef2-9c78-86ad75ea5e96"} == {true},

It feels a bit odd that the use of this syntax doesn't produce an error similar to when the "some ... in" syntax is used. If that's something that you think should be fixed, I can open a bug for it.

[anderseknert]

I think that whole construct is somewhat unidiomatic... but how we best should rewrite it depends on the number of items you intend to put inside of grant_rules and how they'll differ. Would you be able to expand on that?

As for the some keyword not being usable inside of a set "constructor"... I don't know... would you expect that to work in another language?

arr := []string{"txt", for i := 0; ...}

...would obviously not work in something like Go or Java. Comprehensions wrap logic in a body similar to that of rules, so you have more flexibility in terms of what to put there. The reason input.folder_hierarchy[_] == "..." works is likely because a single boolean outcome would be the result of the expression, but that would better be expressed as "abc123" in input.folder_hierarchy in order to do a contains check without iteration.

That Regal recommends some ... in style iteration here is certainly a bug though, and I just filed an issue to fix that. Thanks for the pointer 👍

[robhafner]

Regarding your question, The grant_rules (and deny_rules) array will be defined differently for each service that we have. Each service will have its own policy. Parts of each service's policy is currently duplicated. For example, some of our rules pertain to all services as they match a uri of /* or /**. Other rules which pertain to folder hierarchy authorization are also duplicated in each policy at the moment. We may want to optimize this at some point in the future but the duplication is relatively easy right now for our proof-of-concept as we dynamically generate the policy based upon our existing authorization service rules (developed in house). We don't have a hard limit on the number of rules that may exist in a service. OOTB most services probably have less than 100 or so but our solutions and customers can add additional rules at runtime. On one our tests system I think the average rules per service is some where between 300 and 350 rules.

In general, most of our rules are made up of a combination of the following:

1. Check values from the JWT.
2. Check values based on the request and some metadata associated with the request that we provide as input.
3. Check values associated with a folder hierarchy that we provide as an array of ids.
4. ABAC where the attribute resides in the database. We are attempting to use partial evaluation for this and perform part of the authorization decision using SQL criteria. Our current authorization service supports defining rule conditions using Spring Expression Language (SpEL) and allows any boolean expression to be defined based upon the associated resource's attributes. Cases such as requesting identity is in a particular group or not in a particular group are common.

There are a few other cases that we support that I haven't spent enough time trying to map into OPA just yet. Such as:
https://github.com/orgs/open-policy-agent/discussions/542

We also have a need to make a bulk decision for multiple uris associated with a permission such as read in a single call to OPA. I think this is where the complexity is coming from as we are attempting to use a single set of rego rules to be able to perform an authorization decision for both a single uri/permission and multiple.

[robhafner]

For reference here is an example of the policy for one of our services that has relatively simple authorization requirements. There is currently an issue in some rule conditions which use the "every ... in" syntax which I'm trying to convert to a composition. This policy makes use of the 1-3 options I mentioned in my previous comment.

https://play.openpolicyagent.org/p/95CUCreC3D

[anderseknert]

Another issue with using sets like "rules" rather than actual rules is that OPA is going to evaluate all of the expressions in the set, while evaluation in a real rule would stop at the first false or undefined condition. Let's try and figure out together how to rewrite this :)