Follow these guidelines to make sure you’re using the right security technique for every situation!
Security in ServiceNow is a very important, but often very confusing subject to get the hang of. ACLs, business rules, client scripts, and UI policies can all affect the security in your system to varying levels. Improper use of any of these security mechanisms can cause you some pretty serious problems so it’s important to know what you’re doing. In my experience as a ServiceNow consultant and administrator I’ve learned some things about ServiceNow security that I want all of my clients to know. I’ll explain these things in this article.
Although they are often a critical part of the overall security approach for a ServiceNow instance, this article will not address the details of security restrictions that are initiated outside of a ServiceNow system. These restrictions generally fall into the following categories…
- VPN or other network-based access restriction not configured in your ServiceNow instance
- IP Range-based Authentication Plugin
- Single Sign-on Authentication
What this article will address are the details of security restrictions within the system that affect the fields on a form or list, and rows within tables.
1 – Meet your new best friend…The Access Control List (ACL)
The Contextual Security Manager should be your FIRST AND PRIMARY line of defense when it comes to security in ServiceNow. If an element or record really needs to be secured from all angles, this is the way to do it! You need to become very familiar with how to use ACLs.
2 – Client scripts and UI policies ARE NOT security!
I feel like I should have put a few more exclamation points in on this one.:) This is such an important point to make though because it’s a very common point of confusion for people getting started with ServiceNow.
It’s very simple to set up a client script or UI policy to make a field read only. This works great when you’re looking at a form because that’s the only place where client scripts and UI policies run! What isn’t as obvious is that this “security” can easily be bypassed in a variety of ways. I’m not going to detail all of these, but I will show you the most common scenario…list editing. The following screenshots show the difference in a list between a field that has been secured by an ACL and and field that has been secured by a client script or UI policy. The client script method has no effect in any place other than a loaded form so it doesn’t secure anything in the list.
While it is possible to supplement a client script or UI policy with a ‘list_edit’ ACL, this is still a poor substitute for a truly locked-down field through the use of a full ‘write’ ACL. The bottom line here is that if it really needs to be secure, client-side methods aren’t going to do the job. Client-side methods obviously have their place, but they are designed for masking certain field inputs on a form to control the process of record creation, not permanent security of a field.
3 – Don’t use dictionary settings for security
Each dictionary entry in the system has a few fields that could potentially be used to secure fields in the system. There is a ‘Read only’ checkbox, and ‘Read roles’, ‘Write roles’, ‘Create roles’, and ‘Delete roles’ fields available. The ‘Read only’ checkbox will work, but it will interfere with any ACL security that you put in place and it’s almost guaranteed to cause serious grief for someone trying to troubleshoot a security issue with that element. The ‘roles’ fields only work with the extremely old simple security model that was used several years ago before contextual security ACLs came along. Contextual security ACLs have been the default security model for several years now. The best advice I can give here is to remove these fields from your dictionary form and don’t use them. 🙂
4 – Pay attention to the ‘Row-level read’ ACL exception
There is a major exception to the use of ACLs when it comes to the read operation. It’s probably best to illustrate this with a screenshot of something that you might have seen before…
What this screenshot illustrates is that ACLs securing the read operation for an entire row (TABLENAME instead of TABLENAME.FIELDNAME or TABLENAME.*) do not work well if you’re limiting access to some of the records within a table. The records aren’t visible, but you end up with a list that only shows you the records available for each page in the list (along with a count of all of the records that the user isn’t seeing) rather than a normal, compressed list of just those results that are available. ‘Row-level read’ ACLs should only be used when you want to restrict or grant access to every record in a table to a certain set of users. Any situation that only limits access to some of the records in a table requires the use of a ‘Before query’ business rule to avoid this problem.
I’ve written a couple of articles on ServiceNowGuru explaining how ‘Row-level read’ business rules work. You should read these articles for more details.
Controlling record access with ‘before query’ business rules
Fixing the ‘Before query’ business rule flaw
5 – ‘Before’ business rules and onSubmit client scripts can be used to prevent record submission
There may be specific scenarios where you want to prevent the insertion or update of a record based on something going on in that record or form. In these cases you may use a business rule or client script to accomplish your goal. Full details on this technique can be found here.
6 – Don’t forget to add ACLs for new tables you create
It’s inevitable that you’ll need to create new tables in your ServiceNow instance. It’s important to remember that ACLs for tables don’t automatically get created for you so you have to create them if you want that table to be secure. Usually it’s enough to create some simple read, write, and delete row-level ACLs but it will depend on your setup and the purpose of the particular table. The only exception to this would be instances running the ‘High Security Settings’ plugin or utilizing some other sort of ‘default deny’ ACL model.
7 – Introducing or modifying any top-level (*.*) ACL can cause SERIOUS problems
Top-level ACLs impact the entire security structure of your system. It’s just usually not a good idea to modify them or introduce new ones, so leave them alone.
8 – Understand the ACL rule search order and precedence
This information is critical if you’re working with ACLs because there is a hierarchy of tables and fields and a precedence between different types of rules that needs to be considered. If you’ll educate yourself on this ordering, you’ll be able to make sense of contextual security much more quickly.
Good Post.Thanks for the info on ACLs 😀
Great post Mark. I take your point about using the “before query” business rule in preference to a row-level ACL, but sometimes it is very difficult to construct the query conditions in the business rule, and it’s easier to use a scripted ACL – and live with the security message.
Thanks for the comment. There may be exceptions for extremely small tables, but the security message isn’t really the issue, it’s the fact that you might have to page through thousands of results to see the 5 records in the table that you are allowed to read. Row-level read ACLs don’t collapse all of that data for you down to the first page.
Ah yes – now I understand what you’re saying – you’re right, on the few occasions that I have used a row-level read ACL it has been on small tables where that effect has not been obvious. Brian
thanks for these contents
i learnt a lot of things about the ACL. nice work 🙂
Thanks for your article.