[Music] good afternoon today i'm going to be talking about what access control list rules are in servicenow and how to configure them so basically 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 you know windows or mac computer that we're all familiar with and so for us to examine acls let's type in acl and the quick nav system security access control and so you're probably wondering what types of things can acls control access to so 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 that we see listed here so the next thing we need to be aware of is what types of operations can acls control now 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 also ui actions and 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 so 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 well in this menu we have you know 9000 acls how do we focus in 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 configure security roles and this will give you a general idea of what acls can potentially be called into play when you're accessing this specific resource i'm saying potentially because the order precedence logic gets a little complicated we're going to talk about that in a second but this does give you a full overview of all the acls that potentially come to play now this record that we navigated from is on view example table it extends task so any tables that are inherited from you will also inherit acls from too and so in order for us to understand how acls get evaluated since we have potentially you know a lot of acls here for just that one record i've prepared a basic overview of how acls get evaluated so when you access a table record through a client-side interface basically the system will iterate over every field on the table and it will follow this order of precedence logic and the reason i put it into a soil code block was because you know there's a lot of stuff potentially going on here and i think most of us since we're advanced administrators or at least intermediate level developers can understand soil code relatively easily so basically the system starts with the first field and it says if there is a acl rule for this specific table in this specific field in our example we're doing it against the underscore example table underscore or excuse me dot assigned to then we will evaluate that specific that table specific field acl and we will skip the rest if there is not a specific table specific field acl the next thing the system will look for will be an acl on an inherited table with a specific field so in this example our our example table extends the task table so it would examine the task dot assigned to acl that exists if that does not exist then it will look at the specific table dot wildcard acl it will look for that if that is found it will evaluate the specific table dot wildcard acl if it does not find that it will then look for an inherited table dot wildcard acl if that is found it will evaluate that if it does not find that it will look for a specific table dot none acl so no field specified wild card is technically a field because it says all fields so basically we're moving the system is moving from most specific to most generic as the order of precedence for acl evaluation if it does not find the specific table dot none acl it will then look for inherited table.none acl if it does not find that it will look for a wildcard table dot specific field such as star.cisid if it does not find that it will look for a wildcard table wildcard field acl star.star if it does not find that it will look for a generic wildcard acl and this usually comes into play for resources like ui pages and if it goes through all these other checks and it does not find any of those kinds of acls it will grant permission to the resource this is per the servicenow official documentation under platform security access control list rules so let's say we went through the system went through the order of precedence evaluations and it found a matching acl rule well in this example we have table specific field specific acls on the you example table dot assign to field so what the system is going to do it's going to come over and it's going to start evaluating the first acl and this is the sub process it 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 acl rule if the acl 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 so let's say the acl rule comes back true it will say okay this person is good to go they're allowed to access it 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 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 so we've examined the order of precedence for acl roles and we've also examined how they evaluate let's discuss how we troubleshoot acl problems so we're impersonating a user our favorite user able tutor able tutors not able to modify the assigned to field they need to be able to modify it so how do we see what's really going on here with the acls what we need to do is we need to enable acl debugging so debug security rules under system security go back to our impersonation we're gonna refresh our record and now we're going to get a very detailed data dump here of exactly what is going on with our acls so there is a big wall of text here if you're interested in you know knowing exactly how acls get evaluated you can scroll through all that since you know we we have a mission here we're going to click the debug icon next to the element that we're actually interested in and 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 we'll hit control f hit the down arrow and it's going to take us directly to this acl check that's failing so 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 so 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 the record object task dot assigned to target write operation is failing so what we can do is we can go back to our admin account and then we can go back to this acl rule and we can open the acl directly from there that was failing this is great because i see okay the roll check was failing i need the catalog or the task editor or the itil role so let's say i wanted to modify this i need the security admin role to modify acls and then i need to elevate my role now we'll come back to the acl refresh now let's say that i 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 well the most appropriate thing to do would be the first because this is on the u example table and we're using an inherited acl right now first we need to create one on our specific table acl first because we need to preserve the existing functionality and 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 so we're going to say we're going to create the original task table acl with the roles directly on the new example table say insert with roles and now 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 i'm going to create a brand new acl i'm going to say advanced to get the script field to show up i'm going to say just insert and stay because i do not want the roles to apply on this new acl and now on this new acl i'm 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 other one so we'll say answer the result of your script acl condition needs to go in the answer variable gs.getuser is member of current dot assignment group and we'll save that now that we are impersonating our test user able tutor again we can see we are able to [Music] write to this field now even though able tutor does not have any of those roles that were in the original acl because we can created a parallel acl for that same target let's go down and look at it 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 this is our new aco 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 because our user was part of the assignment group one thing that you should be aware of this kind of a gotcha is called out in the servicenow high portal under this knowledge base article in a purely backend transaction acl rules are not evaluated by default so there are some scenarios like in this specific knowledge base article it says in a ui action if it's not client-facing and it only has back-end code then you can then your users can potentially do things against the database that will not be checked by acls the solution to that is to use the glide record secure class in your back-end code that may possibly have client-side interfacing like ui actions client callable script includes etc so today we discussed how acls work and how to configure them please keep in mind the specific order of precedence that acl use because you know 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 faults 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 glide record secure to enforce acls so hopefully you found this information useful and thank you for watching you