What Is Conditional Table Query Range ACL?
Understanding ServiceNow's Conditional Table Query Range ACLs
I am a technical architect and ServiceNow enthousiast. Since then I have been obsessed with development and later on application design & architecture. Today I'm using my skills to design solutions for IT companies within the ServiceNow industry whilst in my free time, spent the majority of my time creating applications for all kind of things unrelated to ServiceNow.
Earlier this month, ServiceNow rolled out a security change involving new ACL types for which they are mostly documented. Yes, mostly 👀 . We know about query_range and query_match, but have you seen this conditional_table_query_range?
How does it work?
These ACL are different from the regular ACL's. They are defined on table level. As you might have noticed, some of the ACL contains a security attribute starting with SAB_. In these attributes you will find a line of code that looks like this:
new global.SNCAPICallWrapper().hasRightsToConditionalTableQueryRange(['SOME_TABLE_NAME'])
At first you might think, this is blackbox, trying to open the reference gives a record not found. In reality, ServiceNow is just hiding this script include using a before query business rule on the script include table. You can find the link to the business rule here.
After you disabled the business rule, you will have access to the hidden script include.
In that script include, we can find the function that is called by our security attribute.
// work-around for making GlideSecurityManager.get() call available from scoped apps
hasRightsToConditionalTableQueryRange: function(tableName) {
var path = 'record/' + tableName + '/conditional_table_query_range';
var gsm = global.GlideSecurityManager.get();
return gsm.hasRightsTo(path, new GlideRecord(tableName));
},
This piece of code is calling the GlideSecurityManager and evaluates based on the ACL operation and the given table name, if access is granted or not. So if we link all of this logic together, we get the following logical chain:
ServiceNow has multiple query range ACL, some query range ACL contain a security attribute. The security attribute decides if the ACL will evaluate to true or false. The security attribute contains the line of code making a call to our SNCAPICallWrapper script include with it’s corresponding table name.
The wrapper itself contains a hardcoded line to evaluate the result of the ACL, which will assess record access for the provided table name for all ACLs with the operation "conditional_table_query_range." If the ACL evaluates to true, the attribute will also return true, and the ACL will grant access.
What is the use case for this ACL?
These ACL’s have been generated automatically and are considered a boilerplate ACL which may contain a set of security checks that always need to evaluate to true in order to gain access. You can have multiple table.* or even table.field ACL’s call the boilerplate ACL to evaluate the access.
Conclusion
ServiceNow recently introduced new ACL types, including conditional_table_query_range, which operate at the table level and involve hidden script includes like SNCAPICallWrapper. These ACLs use the GlideSecurityManager to determine access rights based on specific security attributes. They serve as boilerplate ACLs, requiring certain checks to evaluate true for access, influencing multiple table-level or field-level ACL evaluations.
