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.

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.

The post What Everybody Should Know About ServiceNow Security appeared first on ServiceNow Guru.

Business Rule / UI Action:

//Check if new record
current.isValidRecord();

You’ll often see a condition like this on UI actions indicating that the UI action should only be available if the record has actually been inserted already…

!current.isValidRecord()

Client Script:

//Check if new record
if(g_form.isNewRecord()){
   alert('This is a new record!');
}

The post Testing for a Valid Record appeared first on ServiceNow Guru.

Removing/Adding Options

You can remove options from a choice list by using the following function call…

g_form.removeOption(<fieldName>, <choiceValue>);

Here are a couple of practical examples…

//Remove the 'Critical' priority option when some field changes
function onChange(control, oldValue, newValue, isLoading) {
   g_form.removeOption('priority', '1');
}

//Remove the 'Closed' state option if the user is not an admin and state is not 'Closed'
function onLoad() {
   var isAdmin = g_user.hasRole('admin');
   var state = g_form.getValue('state');
   if (!isAdmin && (state != 7)){
      //alert('Current user is not an admin');
      g_form.removeOption('state', '7');
   }
}

If you want to remove ALL options from a choice list you can use the following…

g_form.clearOptions('<FIELD_NAME>');

Options can be added to a choice list by using the ‘addOption’ function call…

g_form.addOption(<fieldName>, <choiceValue>, <choiceLabel>, <targetIndex>);

Here’s an example…

//Add the 'Critical' priority option as the second option (--None-- value is option 1) when some field changes
function onChange(control, oldValue, newValue, isLoading) {
   g_form.addOption('priority', '1', '1 - Critical', 1);
}

Disabling/Enabling Options

There is no out-of-box function provided to disable options in choice lists.

The reason for this is that the Chrome browser didn’t support the method and removed the options instead. It is possible to disable choice list options in other browsers though, but you’ll have to provide the function to do so. In order to do that, you can create a new UI Script by navigating to ‘System UI -> UI Scripts’ and entering the following settings:

function disableOption(fieldName, choiceValue) {
   fieldName = g_form.removeCurrentPrefix(fieldName);
   var control = g_form.getControl(fieldName);
   if (control && !control.options) {
      var name = 'sys_select.' + this.tableName + '.' + fieldName;
      control = gel(name);
   }
   if (!control)
      return;

   if (!control.options)
      return;

   var options = control.options;
   for (var i = 0; i < options.length; i++) {
      var option = options[i];
      if (option.value == choiceValue) {
         control.options[i].disabled = 'true';
         break;
      }
   }
}

function enableOption(fieldName, choiceValue) {
   fieldName = g_form.removeCurrentPrefix(fieldName);
   var control = g_form.getControl(fieldName);
   if (control && !control.options) {
      var name = 'sys_select.' + this.tableName + '.' + fieldName;
      control = gel(name);
   }
   if (!control)
      return;

   if (!control.options)
      return;

   var options = control.options;
   for (var i = 0; i < options.length; i++) {
      var option = options[i];
      if (option.value == choiceValue) {
         control.options[i].disabled = '';
         break;
      }
   }
}

Once you have created your global UI Script functions, you can use it in almost the exact same way as the ‘removeOption’ function above. The only difference is that there is no need to prefix the function call with ‘g_form’.

You can disable options from a choice list by using the following function call…

disableOption(<fieldName>, <choiceValue>);

Here are the same examples from above modified to use the ‘disableOption’ call instead of the ‘g_form.removeOption’ call.

//Disable the 'Critical' priority option when some field changes
function onChange(control, oldValue, newValue, isLoading) {
   disableOption('priority', '1');
}

Again, you probably will only want to disable the option if it is not the option selected when the form loads.

//Disable the 'Closed' state option if the user is not an admin and state is not 'Closed'
function onLoad() {
   var isAdmin = g_user.hasRole('admin');
   var state = g_form.getValue('state');
   if (!isAdmin && (state != 7)){
      //alert('Current user is not an admin');
      disableOption('state', '7');
   }
}

Similarly, you can enable options in a choice list by using the following function call. Since the option is not actually removed from the list, it’s not necessary to provide the choice index.

enableOption(<fieldName>, <choiceValue>);

Here’s an example of the ‘enableOption’ call.

//Enable the 'Critical' priority option when some field changes
function onChange(control, oldValue, newValue, isLoading) {
   enableOption('priority', '1');
}

The post Removing or Disabling Choice List Options appeared first on ServiceNow Guru.

Let’s say that I’m in the middle of a Change management deployment and I’m using the ‘Configuration item’ field on my Change form. At the same time, my company is trying to roll out Incident management so there’s also someone from another department trying to make configuration changes to the ‘Configuration item’ field on the Incident form. The Incident management process says that the Configuration item field is optional while Change management says that it should be mandatory. Incident management has a very complex reference qualifier for the field, but Change management doesn’t want a reference qualifier at all. Since there is only one dictionary entry for the Configuration item field, we can’t both have our way if we are making configuration changes on the dictionary entry. Below are a few of the common scenarios where you might see this problem and how you can make it work for all tables that access the shared field.

1- Mandatory fields:

Although there is a checkbox on the dictionary table to make a field mandatory, it should be used ONLY when the field in question should always be mandatory in every situation for every table that uses the field. As this is very rarely the case, it’s usually much more effective just to make the decision early on to use UI policies or Client scripts to make the field mandatory when it should be.

2- Read-only fields:

See #1. The solution to this problem is a little bit different though. Because security in ServiceNow can be applied in a few different ways, you’ll want to make sure to evaluate the options closely. Most of the time, Access Control Rules are your best bet through the System Security application. Depending on the situation (and how critical it is to secure the field in question) you may want to use a UI policy or a Client script to restrict access to the field. Just remember that UI policies and Client scripts only secure an object when it is loaded on the form which may leave your field open via list editing or some other method.

3- Reference qualifiers:

If the field in question is a reference field, then it’s very likely that you’ll end up using a reference qualifier to filter the records presented by the field at some point. If the tables sharing the field don’t all need the same reference qualifier (or if some don’t need one at all) then you’ll want to use an advanced reference qualifier. Constructed properly, an advanced reference qualifier gives you the ability to identify the querying table before reference qualifier is returned. This means that you can give each table its own reference qualifier, or no qualifier at all. Here’s a sample script that could be used for a Configuration item field shared between various task tables.

function myRefQualFunction() {
var answer;
switch (current.getTableName()) {
case 'incident':
answer = 'sys_class_name=cmdb_ci_computer^ORsys_class_name=cmdb_ci_service^';
break;
case 'problem':
answer = 'sys_class_name=cmdb_ci_server^';
break;
case 'change_request':
answer = 'sys_class_name=cmdb_ci_service^';
break;
case 'change_task':
answer = 'sys_class_name=cmdb_ci_service^';
break;
default: answer = '';
}
return answer;
}

4- Labels:

This isn’t a dictionary setting, but the concept here is the same. Before you go and personalize the label for a field, you really need to be aware of all of the places that field is used. Changing the label of the ‘Configuration item’ field on the Incident form to ‘Incident CI’ would work great for incidents, but not so great for Change requests. It is possible to set up a separate label entry for the same field on each individual extended table.

5- Default values:

There’s only one place to set a true default value for a field…the dictionary entry for the field. Client scripts can set default values, but that value is only applied when the form loads for a particular record. Here’s a script that I’ve used before to set different default values for the ‘State’ field on the Task table. You would place this in the ‘Default value’ field on the dictionary entry of the field in question.

javascript:
switch (current.getTableName()) {
case 'incident': '1'; break;
case 'problem': '2'; break;
case 'change_request': '1'; break;
case 'change_task': '-5'; break;
default: '1';
}

6- Choice lists:

It’s very easy just to right-click on a choice field and select ‘Personalize choices’. While this option is very simple, it doesn’t always supply you with all of the information you need to make an informed decision about how and where the choice should be added. By selecting ‘Show choice list’ you can see exactly how the choice list is set up for all tables involved. Personalizing choices for a choice field is very straight-forward, you just need to be sure of the scope of the choices you are personalizing. A ‘State’ value of ‘Pending acknowledgment’ may make perfect sense in the Incident world, but might not be useful or needed for a Change task. Fortunately, you can specify unique choice values for each extended table that shares the same field.

The post One Field Shared Between Many Tables appeared first on ServiceNow Guru.