With Aaron Elder
In this article, you will learn about what access control list (ACL) rules are in ServiceNow and how to configure them. An access control list rule is a way that the system decides whether or not to allow a user to access a resource. It's very similar to the file system permissions on your Windows or Mac computer that we're all familiar with.
For us to examine ACLS, type in acl in the quick nav and navigate to System Security > Access Control. You're probably wondering what types of things can ACLS control access to. The most conventional thing that an ACL would control access to would be a database record; it can also control access to scripted REST APIs, UI pages, and the other options listed on the screen. You need to be aware of what types of operations can ACLs control. Keeping in mind the most conventional use case example is the database record access, we have some operations here that relate directly to that, such as create, read, write, and delete. Execute comes into play more for scripted REST APIs and UI actions. Report on and report view can control whether or not someone is allowed to create a report against a resource and whether or not they're allowed to view a report created against a resource.
Now that we’ve reviewed the types of objects that ACLs can be applied against and the type of operations that ACLs can control, let's examine some ACLs themselves. In this menu we have 9,000 ACLs, so how do we focus on one that's relevant to us? The easiest way is to go to a specific record for the table that you want to view the ACLs for. Go to the hamburger menu and select configure > security roles. This will give you a general idea of what ACLs can potentially be called into play when you're accessing this specific resource.
This record that we navigated from is on the u_example table. It extends tasks, so any tables that are inherited from you will also inherit ACLs from. In order for us to understand how ACLs get evaluated, since we have a lot of ACLs here for just that one record, we’ll cover a basic overview of how ACLs get evaluated.
How ALCs Get Evaluated
When you access a table record through a client-side interface, the system will iterate over every field on the table, and it will follow this order of precedence logic. he reason we put it into a soil code block is because there's a lot of stuff potentially going on here and soil code can be understood relatively easier. The system starts with the first field, and it says: if there’s an ALC rule for this specific table in this specific field — in our example we're going to be doing it against the u_example_table.assigned_to — then we will evaluate table-specific field ACL and we will skip the rest. This is per the ServiceNow official documentation under platform security access control list rules.
Let's say we went through the system, through the order of precedence evaluations, and it found a matching ACL rule. In this example, we have table specific field specific ACLs on the u_example_table.assigned_to field. The system is going to start evaluating the first ACL. The sub-process will say: does this ACL rule have roles defined: yes or no? If the answer is yes, it will say: does the user have at least one of those roles? If the answer to that is yes, it will then look and see if there are conditions defined on the ALC rule. If the ALC conditions return true, it will then look to see if there is a script defined in the ACL rule. If there is a script defined and the answer variable is true at the end of the script evaluation, it will return a true result for the ACL rule.
Let's say the ALC rule comes back true. It will say: okay this person is good to go and they're allowed to access it. However, if the result comes back false it will then check to see if there are other ACL rules with the same order of precedence on the same target. If that is the case, it will then do the individual ACL rule evaluation again on that other ACL rule that it found. It will repeat this process until it exhausts all the ACL rules with the same order precedence on the same target. If the result to any one of those is true it will grant access, but if the result for all of those is no and it cannot find any further ACLs with the same order of precedence and the same target, it will deny access.
How to Troubleshoot ACL Problems
We've now examined the order of precedence for ACL rules and how they evaluate. Let's discuss how we troubleshoot ACL problems. We're impersonating a user, our favorite user, ble Tutor. Able Tutor is not able to modify the assigned to field, but they need to be able to modify it. How do we see what's really going on here with the ACLs? We need to enable ACL debugging by navigating to Debug Security Rules under System Security.
We go back to our impersonation and refresh our record. We're going to get a very detailed data dump here of exactly what is going on with our ACLs. There is a big wall of text shown on the screen — if you're interested in knowing exactly how ACLs get evaluated you can scroll through that. Since we have a mission here, we're going to click the debug icon next to the element that we're actually interested in.
We're going to say okay this is the permission that we're interested in understanding why it's not working, so we'll highlight that, hit Control F, hit the down arrow, and it's going to take us directly to this ACL check that's failing. The way these checks are laid out, the second X or check mark is a roll check on the ACL rule. The third check is the condition check on the ACL rule, and the fourth check is the script evaluation on the ACL rule. We can see here by mousing over it that the roll check on this ACL is failing, and if we go over here to the right hand side, we can see exactly what ACL is failing on us. In this case, that is the record/task.asigned_to/write operation.
Creating a Second ACL
From here, we can go back to our admin account. Then we can go back to this ACL rule and open the ACL that was failing directly from there. This is great because you can see the role check was failing, soYou need the catalog, the task editor, or the ITIL role. Let's say you wanted to modify this. To modify ACLs, you need the security admin role. After you elevate your role, we'll come back to the ACL and hit refresh. Let's say that you wanted to create a second ACL that would allow our test user, Able Tutor, to write to the assigned to field if he does not have any of these roles.
Because this is on the u_example table and we're using an inherited ACL right now, we first need to create one on our specific table ACL. This is because we need to preserve the existing functionality. If we just go ahead and create a brand new script ACL without creating a backup of this on the specific table, it will just not evaluate that previous functionality. We're going to create the original task table ACL with the roles directly on the new example table — select Insert with Roles. That we've created a specific ACL for this field on our specific table, it's going to mask the ACL that it inherited for that specific field from the parent table. We'll hit Continue, and we've preserved our previously existing functionality on our new specific table ACL, so now we’re going to create a brand new ACL. We’re going to select advanced to get the script field to show up, and select Insert and Stay because you do not want the roles to apply on this new ACL.
On this new ACL, we’re going to script it so that if someone is a member of the assignment group, they can change the assigned to field without needing those roles that were being checked on the previous example. Refer to the video to view scripting at 14.31. This happens because we created a parallel ACL for that same target. Let's go down and look at where it's evaluating. We're allowed to write to the assigned field; this is the original role-based ACL rule that we copied from the task table. We can see our new ACL rule that was only the script condition; it passed the role check because there were no rules specified. It passed the condition check because there was no condition specified, and it passed the script check because the script evaluated for true, since our user was part of the assignment group.
One thing that you should be aware of is called out in the ServiceNow HI portal under the shown knowledge base article. In a purely backend transaction, ACL rules are not evaluated by default. Here is an example given by this knowledge base article:'n a ui action, if it's not client-facing and it only has back-end code, then your users can potentially do things against the database that will not be checked by ACLs. The solution is to use the GlideRecordSecure class in your back-end code that may possibly have client-side interfacing like UI actions, client callable script includes, etc.
Today we discussed how ACLs work and how to configure them. Please keep in mind the specific order of precedence that ACL uses because there are potentially a lot of overlaps, and you have to understand the order of precedence to understand what the net ACL evaluation outcome will be. You should also remember that having multiple ACLs against the same target with the same order precedence will evaluate sequentially until one of those returns true or all of them return false. ACL debugging through the system security debug security rules is the most thorough view into how live ACLs will evaluate. You can use the field specific debugging icons to quickly focus on the relevant information in the ACL debug output, and if your client side script includes and UI actions are potentially interacting with the database, it’s recommended to use GlideRecordSecure to enforce ACLs.
Did you find this How to Use Access Control List (ACL) Rule article helpful? Are you ready to start your journey with ServiceNow? If you want to find out more information about GlideFast Consulting and our ServiceNow implementation services, you can reach out to us here.
About GlideFast Consulting
GlideFast is a ServiceNow Elite Partner and professional services firm that provides tailored solutions and professional services for ServiceNow implementations, integrations, managed support services, application development, and training. Reach out to our team here.