Xanadu: New ACL feature: 'applies to' (explanation on feature, no question)

[Mark Manders]

This is not a question, but since only a few people can create blogs or articles, I am putting it here.

With the new Xanadu release, the 'deny-unless' ACL is introduced. When I was checking on that feature, I noticed a new field on the ACL form: 'applies_to'. This field seems to have the exact same possible entries as the 'conditions' field and after lots of waiting, ServiceNow provided me the answer on the difference. It is not in the release notes, because "it's not a major feature worthy of being in there", but since it can cause lots of confusion, I requested it to be added. Hopefully they will.

The explanation:

An ACL is created to run on a table, a record or a field (i.e. incident, incident.* or incident.field).

• 'applies_to' determines whether the ACL applies to records, data condition is evaluating the ACL that is already applied. The system checks on the table and applies to to see if the ACL needs to be evaluated for the conditions. This makes for a more granular defining of ACL's.
• 'applies_to' specifies if the ACL affects to a specific record. If it's not set (empty), the ACL will apply to all records.
• Data 'condition' results in the ACL evaluation either allowing or blocking access, based on if it matches or not.

It will be more clear when using an example (especially check out scenario 3):

Number	Priority	Location	Assigned to
INC 1	1	NL	User A
INC 2	2	NL	User B
INC 3	1	UK	User A
INC 4	3	UK	User B

ACL Scenario 1

Table = incident

Applies_to: location is NL

Condition: assigned_to is dynamic me

Records on which ACL will be enforced

Number	Priority	Location	Assigned to
INC 1	1	NL	User A
INC 2	2	NL	User B

Allowed to see the record

Number	Priority	Location	Assigned to
INC 1	1	NL	User A
INC 2	2	NL	User B

ACL Scenario 2

Table = incident

Applies_to: assigned_to is dynamic me

Condition: location is NL

Records on which ACL will be enforced

Number	Priority	Location	Assigned to
INC 1	1	NL	User A
INC 3	1	UK	User A

Allowed to see the record

Number	Priority	Location	Assigned to
INC 1	1	NL	User A
INC 3	1	UK	User A

NOTE: Selected records on which the ACLs were enforces are different for both ACLs, however, they both can achieve same result based on how the applies_to and data conditions are configured

ACL Scenario 3

Table = incident

Applies_to: location is NL AND assigned_to is dynamic me

Condition: empty

Records on which ACL will be enforced

Number	Priority	Location	Assigned to
INC 1	1	NL	User A

Allowed to see the record

Number	Priority	Location	Assigned to
INC 1	1	NL	User A

This will deny access to the data, because there is no condition to be evaluated

ACL Scenario 4

Table = incident

Applies_to: empty

Condition: location is NL AND assigned_to is dynamic me

Records on which ACL will be enforced

Number	Priority	Location	Assigned to
INC 1	1	NL	User A
INC 2	2	NL	User B
INC 3	1	UK	User A
INC 4	3	UK	User B

Allowed to see the record

Number	Priority	Location	Assigned to
INC 1	1	NL	User A
INC 2	2	NL	User B
INC 3	1	UK	User A
INC 4	3	UK	User B

[Jake V]

Example 3 I don't believe to even be possible, as every ACL must have a condition, be it a role, data condition, or script. 

The applies to and conditions serve different purposes, "applies to" decides whether to evaluate an ACL based on a condition, the "conditions" (roles, data conditions, script) are then evaluated and allow access if they are all true.

Before Deny Unless ACLs, everything was based on "Allow if" so it wasn't necessary to specify "applies to" as you could define the applicable data to allow by using the data conditions or a script. Now that we have Deny Unless ACLs, the "Applies to" field is necessary because we need to define which records we want to Deny or Allow. The conditions area is still needed as this defines what is required to be allowed, regardless of if its an "Allow if" or "Deny unless". For example, I may want to selectively Deny access to inactive tasks unless they are assigned to me and I have the itil role, so my "applies to" would be Active = False but I also need a data condition of Assigned to = Me and a role of itil. The result is all inactive records are denied UNLESS I have the itil role and the task is assigned to me. 

[tsdexter]

What causes certain ACLs to be skipped? I thought it was specificity...for example, if there are field level ACLs and table level ACLs, the field level would be evaluated first in case there is a deny there. 

I am trying to use the new `applies_to` field for some pre-filtering to only run the ACL on a specific set of records. It seems to filter the records properly and says "matches 220 records" (of many thousands). The ACL is simple, it's for 'read' with `allow if' and 'role=admin' (plus the applies to filter). However, when I run it through access analyzer, my ACL is marked as 'skipped'. The only one that runs is a table level read which allows read access on the whole table to `sn_request_read` role - since the user has this role, they can read it. 

Shouldn't the "applies to" be considered "more specific" ... If I have a read ACL that allows read access to the whole table and then another read ACL that limits read access to certain records (applies to) to only a certain role, shouldn't the presence of "applies to" make it more specific and cause it to run before the table level read ACL without any appleis to filters?

[Mark Manders]

First: it's the other way around. Check is done to see if you have access to the table, then the record and then the field. Because if you aren't allowed on the table, you won't be able to see the field at all. 

Without sharing the exact ACL, it's not exactly clear how you set it up. But if you are allowing access to the sn_request_read role and you are allowing admins the same access, both will have access. Although admin is a weird role to test with, you are saying that sn_request_read has access to all and the admin only to a subset (if it wouldn't be the admin). Put your 'applies to' into the condition, instead of the 'applies to' and it will probably work, but again, without your actual setup, it's impossible to reproduce and test.

[Chris D]

Agreed with the comment that example #3 is practically impossible because there should always be a condition (like snc_internal role) so, functionally (to the end user), Applies To and Data Condition are basically interchangeable.

As far as I can surmise, the difference - and (potential) benefit - is that Applies To runs FIRST, before the Conditions and even before the Security Attribute (presumably). So let's say you have a complex scripted Security Attribute or Condition, if you narrow it down first with an Applies To, you can be more efficient by not running that script unless it's absolutely needed. It's basically a pre-filter.

But a tradeoff is that - because the ACL is never being evaluated - it may be harder to debug access and you may perhaps lose some security logging that could be helpful.

[Simon Ohle 1]

This helped a lot, thank you!