ACL order of evaluation for multiple rules on the same level for the same object

[lbettsdev]

Hi everyone, 

I know that with ACL's, the outermost order of evaluation is: Table, Field, Record. However, often times each object will have multiple ACL's of the same type for the same object (e.g., a table may have 10+ 'read' rules, or a field may have 5+ 'write' rules). What determines the order that they are executed/processed on the 'Execution Path'? I think read somewhere that the order of evaluation for multiple ACL's of the same type on the same object goes from most specific to least specific. But, how does the machine/processor determines what qualifies one rule to be more 'specific' than the other? 

Also, why is it that on the Access Analyzer, when reading multiple rules of the same type for the same object, the order of rules on the Access Analyzer are in a different order to the rule order shown on 'Show Execution Path'? For example, rule (1) on the Access Analyzer for 'read' on a table may show up as being e.g. rule (3) on the 'Show Execution Path'? 

It is so, so hard to find an actual answer for this. I don't know why the documentation seems to have skipped the order of evaluation for multiple rules of the same type on the same object, or why it is so hard to find. 

Thanks in advance if you can help!! I really appreciate it. 

[Bhimashankar H · Accepted solution]

Hi @lbettsdev ,

Please go throw the below community post to get better understanding Access Control in ServiceNow with 'Deny Unless' ACLs .

The order of execution of ACL you can understand like

When deciding whethere to grant or deny access ACL will evaluate from most specific to most generic
1. Match the table and field name: x_58872_needit_needit.short_description
2. Match the parent table and field name: task.short_description
3. Match any table with the field name: •.short_description
4. Match the table and any field (wildcard): x_58872_needit_needit.•
5. Match the parent table and any field (wildcard): task.•
6. Match any table (wildcard) and any field (wildcard): •.e

When an ACL Grants Access 

If the system evaluates an ACL and the result is GRANT, the entire evaluation process for that object STOPS.

• Reason: The goal has been achieved. The user has proven they have permission. There is no need to check any broader, less specific rules.

• Rule: The first true wins and ends the search.

When an ACL Denies Access 

If the system evaluates an ACL and the result is DENY, the evaluation CONTINUES to the next-most-specific ACL in the hierarchy.

• Reason: A single denial is not the final word. The system must continue searching to see if a broader rule might still grant the user access. The user is only locked out if they exhaust all possibilities and never find a rule that says "yes".

• Rule: A false result simply passes the torch to the next ACL in line.

Example Analogy:

Assume we have two read ACLs:

1. incident.short_description (Most Specific): The script on this ACL checks if the user is a member of the 'Service Desk' group.  and our user is not a member.

2. incident.* (Most Generic): This ACL grants read access to all fields on the Incident table if the user has the itil role. and our user does have the itil role.

Here is the execution path:

1. Evaluate incident.short_description: The system checks this rule first. The user is not in the 'Service Desk' group, so this ACL returns false (DENY).

2. Continue Processing: Because the result was false, the system does not stop. It moves to the next rule in the specificity list.

3. Evaluate incident.*: The system checks this rule. The user has the itil role, so this ACL returns true (GRANT).

4. Stop Processing & Final Result: Because this rule returned true, the evaluation stops. The user is granted access to read the short_description field.

Access is only truly denied if ALL applicable ACLs, from most specific to most generic, are evaluated and NONE of them return true. If even the very last, most generic rule (*.*) grants access, the user gets in, overriding all the more specific denials that came before it.

These just explained about the read/write role on table. There are other main important acl operation about reports are report_view and report_on.

Thanks,
Bhimashankar H

-------------------------------------------------------------------------------------------------
If my response points you in the right directions, please consider marking it as 'Helpful' & 'Correct'. Thanks!

[lbettsdev]

Hi @Bhimashankar H , 

Thank you for your response. That clarifies many questions, thank you.

However, I am still seeking to find out what the order of execution is multiple ACL rules are at the same point of processing. I have attached a screenshot. 

[Bhuvan]

@lbettsdev 

ACLs are run most specific to least specific. Let us take for example, you created 2 ACLs with same match conditions for table.field 'incident.number'.  User has to meet conditions of at least 1 ACL rule to be given permission for the object, in this example number field for incident table.

Refer below link for more details,

https://www.servicenow.com/community/itsm-forum/how-are-multiple-acl-rules-at-the-same-point-in-the-...

Thanks,

Bhuvan

[Bhimashankar H]

You can check using debugging the for any user by session log, that will give you clear idea.

System Diagnostics > Script Debugger > Session Debug

Take any example from your PDI and check how many ACL it should pass through and which gives access, and which denies access.

Thanks,
Bhimashankar H