Security rule efficiency - 1 complex vs 2 simpler

[gandalfgray]

Hi!

Is there any significant difference in performance splitting a "complex" security rule into two simpler?

If so, which is better for performance?

Example:

A (one rule):

((user.group=resource.@access_group) and (user.group="data.access.qs.superuser" or user.group="data.access.qs.poweruser"))

B1 (first of two rules):

((user.group=resource.@access_group and user.group="data.access.qs.superuser"))

B2 (second of two rules):

((user.group=resource.@access_group and user.group="data.access.qs.poweruser"))

[Marc · Accepted solution]

Order of execution in rule syntax matters  (Examples 5 & 6) so it would actually be more performant to do it this way, so that the Rule Fails if the user is not in the Groups without having to resolve the custom property value 

((user.group="data.access.qs.superuser" or user.group="data.access.qs.poweruser") and (user.group=resource.@access_group))

[gandalfgray]

Ok, thanks @Marc  I see,

but then again, is there any significant performance difference between your suggested single rule and having the following two rules instead?:

R1:

((user.group="data.access.qs.superuser") and (user.group=resource.@access_group))

R2:

((user.group="data.access.qs.poweruser") and (user.group=resource.@access_group))

If these two has the exact same Resource filter, Actions and Context, and the first evaluated rule returns True is the second rule not evaluated?

[Marc · Accepted solution]

In the scenario where the user matches against the first rule, there will be a very slight difference in performance.

if they match against the second rule there is a greater increase in overhead 

and if they don't match against either rule then there is more overhead again.

if the user was in both superuser & poweruser groups, but not in the resource.@access_group the overhead would be even higher again.

so yes, there would be greater overhead having two rules instead of one.

Rules should fail fast, with the least expensive operations first.

Should be as concise and targeted as possible

Should not use LIKE unless absolutely necessary (this adds significant performance overhead)