ACL

This article is a supplement to the ServiceNow documentation. For full documentation please refer ServiceNow official website

Checkout our NEW Video Channel you can like and subscribe too!

Introduction

An instance uses access control list (ACL) rules, also called access control rules, to control what data users can access and how they can access it. ACL rules require users to pass a set of requirements in order to gain access to particular data.

Users with the admin role can view Access Control records but cannot create, delete, or update Access Controls. All Access control operations except read require elevated security privileges. Elevated security privileges are also known as the security_admin role.

In the Elevate Roles dialog, select security_admin then click the OK button.

Access Controls can be created for

Records
Client callable Script Includes
Processors
REST Endpoints
UI Pages

There are four sections in Access Controls

Table/field
Requires Role
Condition
Script

In order for permission to be granted to access a table/field, the Requires Role, Condition, and Script sections must all return true. If there is no value, the section returns true.

Table/Field

Use the Name field in the Access Control configuration to specify which records and which field are secured.

The example rule is a write rule:

Write: [incident] [Email Received Date]

Requires Role

Use the Requires role list to specify the role(s) required to access records. Click the Insert a new row… line to add a role to the list. If there are multiple rows in the list, the user only needs one of the roles for Requires role to return true.

Condition

Use the Condition field to create the condition(s) required to grant access. In the example, the Requested for value must be the currently logged in user.

Script

Select the Advanced option to see the Script field.

Access Control scripts execute server-side. For best performance, avoid Access Control scripts that use GlideRecord queries as they can adversely impact performance.

Restrict the script logic only to security-related logic. If other logic is included, such as managing date formats or validating record data, it can be difficult to debug problems in the future as you might not think to look in Access Control scripts for those actions.

Some useful methods for Access Control scripts include

GlideSystem: getUser(), getUserID(), getUserName(), hasRole(), isLoggedIn(), isInteractive(), getSession()
GlideRecord: isNewRecord()

Access Control scripts must set the answer variable to true or false.

Access Controls Evaluation Order

Access Controls do not stand alone; they are part of list known as an Access Control List (ACL). An ACL is an ordered list of all Access Controls that apply in a particular circumstance.

Recall that the incident table extends the Task table.

Due to inheritance, the Task table Access Controls can potentially grant or deny access to Incident table records if no Access Controls specific to the Incident table exist. If no Access Control exists on the table, the parent table Access Controls are searched.

When deciding whether to grant or deny access, the ACL is searched from the most specific to the most generic match. For example, when determining whether to grant access to the Incident table Short description field, the search order is:

- Match the table and field name: x_58872_incident.short_description
- Match the parent table and field name: task.short_description
- Match any table with the field name: *.short_description
- Match the table and any field (wildcard): x_58872_incident.*
- Match the parent table and any field (wildcard): task.*
- Match any table (wildcard) and any field (wildcard): *.*

Access Control Configuration Watcher

When Access Controls are submitted or updated The Access Control Configuration Watcher runs to determine if there are other Access Controls acting on the same set of records. The Access Control Configuration Watcher displays a list known as the execution plan. The results are indicated by:

Red text: An Access Control that was activated or deactivated.
Blue text: An Access Control that was modified.
Green text: An Access Control that is added or has become active.
Masked: An Access Control that was effective until you made a change.
Unmasked: An Access Control that was made effective when you made a change.

The Access Control Configuration Watcher also indicates whether the Access Control affects table rows or fields. Select the Show All link to see the complete ACL and not just the Access Controls impacted by the change.

*To or Not to *

The Name field in an Access Control specifies the table records to protect and a field to protect. The field list has a –None– option and a * option.

–None–: Grant access to records and all fields in the records.
*: Grant access to all fields where there is no field-specific Access Control.

At first glance, --None-- and * seem to grant the same thing: access to all fields on a record.To tell the difference in behavior, review how --None-- and * work together and with other Access Controls in a demonstration.

To summarize

When creating * Access Controls, also create a None Access Control because only None grants access to records. When writing an ACL that mostly grants access, use only None. When writing an ACL that mostly denies access, use None and *.

Lets Demo it

The examples use an application called Generic that has a single table called Table. Table has five columns: Field 1, Field 2, Field 3, Field 4, and Field 5.

app_store_learnv2_securingapps_kingston_app-store_SecuringApplications_SecuringAgainstUnauthorizedUsers_Images_Secure_GenericTableFields311019.png

The application has two roles:

x_58872_generic.admin, assigned to Fred Luddy x_58872_generic.table_user, assigned to Beth Anglin app_store_learnv2_securingapps_kingston_app-store_SecuringApplications_SecuringAgainstUnauthorizedUsers_Images_Secure_GenericAppExplorer2311019.png

None – without

Examine the two read Access Controls. Pay attention to the field value and the roles. The screenshots have been edited to show only the pertinent parts of the Access Control.

app_store_learnv2_securingapps_kingston_app-store_SecuringApplications_SecuringAgainstUnauthorizedUsers_Images_Secure_Case1None3311019.png

Using this Access Control List (ACL), Fred can see:

Fred can see all rows all fields app_store_learnv2_securingapps_kingston_app-store_SecuringApplications_SecuringAgainstUnauthorizedUsers_Images_Secure_Fred15311019.png Using this ACL, Beth can see:

Beth cannot see Field 3 app_store_learnv2_securingapps_kingston_app-store_SecuringApplications_SecuringAgainstUnauthorizedUsers_Images_Secure_Beth16311019.png

*How does this work?

The None Access Control granted all rows and all fields to both Fred and Beth. The Field 3 Access Control granted Field 3 access to Fred. Giving Field 3 explicitly to Fred removed Field 3 access from Beth even though she was granted Field 3 access by the None Access Control.

None – with

Examine the three read Access Controls. Pay attention to the field value and the roles. The screenshots have been edited to show only the pertinent parts of the Access Control.

app_store_learnv2_securingapps_kingston_app-store_SecuringApplications_SecuringAgainstUnauthorizedUsers_Images_Secure_Case2None7311019.png

Using this ACL, Fred can see:

Fred can see all fields and all rows app_store_learnv2_securingapps_kingston_app-store_SecuringApplications_SecuringAgainstUnauthorizedUsers_Images_Secure_Fred210311019.png

Using this ACL, Beth can see:

Beth can see only Field 3

app_store_learnv2_securingapps_kingston_app-store_SecuringApplications_SecuringAgainstUnauthorizedUsers_Images_Secure_Beth211311019.png

How does this work?

The None Access Control granted all rows and all fields to both Fred and Beth. The * Access Control granted all rows and all fields to Fred. It seems redundant to have this Access Control because Fred already had access to all rows and all fields. The purpose of this Access Control is to deny access to all other roles, even roles granted permission by the None Access Control. The Field 3 Access Control explicitly gives Beth access to Field 3 even though Beth was denied access to Field 3 by the * Access Control. Field-specific Access Controls take precedence over * Access Controls.

Conclusion

You cannot write * Access Controls without None because only None grants access to records.
When writing an ACL that mostly grants access, use only None.
When writing an ACL that mostly denies access, use None and *.

UX_Page ACL

Goto sys_security_acl table and create a new record .The type will be ux_page.The most important part here is the “Name” field.

The Name field is hybrid field it can acts as reference field as well as plain text field. We are going to use as plain text field and provide the full path of the url of the ux page

Format to follow

Suppose our url is :

https://dev567.service-now.com/x/xyzpc/my-portal/hello-world-app-2

(snowinstance)/x/(companycode)/my-portal/hello-world-app-2

Then the transformed Name will be

x.(companycode).my-portal.hello-world-app-2