Securing Applications against Unauthorized Users Objectives

In this module you will learn to:

 Create and use roles and groups

 Impersonate users to test authorizations

 Allow access to applications and modules

 Use Access Controls to protect table records from unauthorized access:

 Create

 Read

 Update

 Delete

 Debug Access Controls

 Use methods from the ServiceNow API to script security

Users, Roles, and Groups

Securing applications against unauthorized access starts with roles. Roles control access to
features and capabilities in applications and modules.

To create roles, select the Create Application File button in Studio. Select the file type Role and
click the Create button. Configure the role:

SURESH SNOW Page 1

  Suffix: Unique part of the Name field. Appended to the scope in the Name field.

 Name: Name of the role. Appears in fields when assigning roles.

 Assignable by: Role that can assign this role to users and groups.

 Application: The application containing this record.

 Elevated privilege: Select this option to mark this role as required to elevate to high
security. Roles that require users to elevate to high security grant modification access to
the High Security Settings and allow the user to modify the Access Control List, directly
import XML files, and access the Scripts - Background module.

 Description: Description of the role’s intended use.

To assign a role to a User, use the Application Navigator in the main ServiceNow browser
window (not Studio) to open User Administration > Users.

Open a User record from the list. Scroll to the Roles section and select the Edit… button.

1. Select the role to add from the Collection slushbucket. NOTE: There can be thousands of
roles in the database. The slushbucket loads the first one hundred roles. If you don’t see
your role in the first one hundred roles, use the search field to locate the role.

2. Select the role to add by clicking on it.

3. Use the Add button ( ) to move the role to the Roles List.

4. You should see the role in the Roles List.

5. Click the Save button.

SURESH SNOW Page 2

User administration is not part of an application’s files. That is to say, adding a role to a user is
not captured as part of an application. When the application is installed on another instance the
installation process will not update user records with roles.

Groups

A group is a set of users who share a common purpose. Groups may perform tasks such as
approving change requests, resolving incidents, receiving email notifications, or performing
work order tasks.

Groups are a shortcut way of assigning roles to users. Rather than adding a role individually
to each user, assign a role to a group. Group members have all of the roles assigned to a group.

To create groups, use the Application Navigator in the main ServiceNow browser window (not
Studio) to open User Administration > Groups. Click the New button. Configure the group:

SURESH SNOW Page 3

  Name: Name of the group.

 Manager: Group manager or lead.

 Group email: Group email distribution list or the email address of the group’s point of
contact, such as the group manager.

 Parent: Other group of which this group is a member. If a group has a parent, the child
group inherits the roles of the parent group. The members of the child group are not
members of the parent group.

 Description: Description of the group’s intended purpose.

After creating a group, switch to the Roles section. Click the Edit… button. Add roles to the
group using the slushbucket. Select the Save button after the role(s) have been added.

Switch to the Group Members section. Select the Edit… button. Add the desired users to the
Group Members List using the slushbucket. As with all slushbuckets, only the first one hundred
users are loaded into the slushbucket from the database. You may have to use the search field to
locate the users of interest. Select the Save button after all user(s) have been added.

The NeedIt Users group has one role and two members.

SURESH SNOW Page 4

Group administration is not part of an application’s files. That is to say, when an application is
installed on another instance, no groups will be created or updated on the target instance.

Securing Applications and Modules

Applications

Access to an application in the Application Navigator is controlled by the Application’s User

role. It is not required to restrict application access if roles are applied to modules.

To add an application user role, open the application for editing in Studio. Open the File menu
and select the Settings menu item.

SURESH SNOW Page 5

Add a role to the User role field to limit application access to users with a particular role.

Access to Applications can also be set at the Application Menu level. In the Application
Navigator, open Navigation > Application Menus > <application name>.

In order for users with no role to see modules, both the module and the application menu must
have no role.

Modules

Access to modules in the Application Navigator is controlled by roles. Set a module’s Roles in
the Visibility section.

Use the Override application menu roles option to give module-level access to a role that is not
authorized to see the application. For example, assume the NeedIt menu requires the admin role
SURESH SNOW Page 6
and a module for the NeedIt application requires the approver_user role. The application-level
requirement supersedes the module-level requirement which means that users with the
approver_user role cannot see either the application or the module. If the Override application
menu roles option is selected, users with the approver_user role can see both the application and
the module even though the user is not authorized by role to see the application.

Tables

When creating tables in scoped applications, you must assign a role to the table. In the default
case, only users with the table’s role can create, read, update, and delete table records. Configure
the User role in the Controls section of the table form. You can dynamically create a new role or
assign an existing role.

Impersonating Users

Impersonation allows users with the admin role to temporarily become another
authenticated user for testing purposes. When impersonating another user, the admin user can
see and do exactly what the impersonated user can do. Impersonation does not require
knowing the user’s password.

Impersonation is done from the main ServiceNow browser window (not Studio). Open the User
menu by clicking your user name in the ServiceNow banner. Select the Impersonate User option.

SURESH SNOW Page 7

In the Impersonate User dialog, enter the name of the user to impersonate in the Search for user
field.

Select the user from the drop-down list. ServiceNow reloads and you are now beth.anglin and
can test access as if you had logged in with Beth’s user name and password.

After testing, return to the admin user by impersonating again. Click on Beth Anglin in the
banner to open the User menu. Click Impersonate User. From the Recent Impersonations list
select System Administrator.

SURESH SNOW Page 8

 Exercise: Roles and Groups
In this exercise you will create a role and two groups for the NeedIt application. You will add
roles and group members to the groups.

Examine Application and Module Roles

1. If the NeedIt application is not open in Studio from the last exercise, open it now.

a. In the main ServiceNow browser window use the Application Navigator to open System
Applications > Studio.

b. In the Load Application dialog, click the NeedIt application.

Determine if the application has an application file of type Roles.

. In the Application Explorer, look for Access Control > Roles.

SURESH SNOW Page 9

a. You should see one role. Make a note of the role name.

Determine if the application has a User role assigned to it.

. Open the File menu and select the Settings menu item.

a. Scroll to the User role field. Does the field have a value?

b. Close the tab for the Application Settings.

Determine if the Application Menu has a role assigned to it.

. In the Application Explorer, open Navigation > Application Menus > NeedIt.

a. Examine the Roles field. Make a note of the role name.

b. Close the Application Menu tab.

Examine the role(s) for the NeedIt modules.

. In the Application Explorer, open Navigation > Modules > All.

a. In the Visibility section, examine the Role field. Make a note of the module role.

b. Look at the Roles field for the Create New and Open modules. Are all the roles the same?

Create a Role

It is common for applications to have an application admin role in addition to an application user
role. Application admins have access to modules that users do not. In this part of the exercise
you will create an admin role for the NeedIt application.

1. Create a role.

a. In Studio, click the Create Application File button.

b. In the Filter… field enter the text Role OR select Access Control from the categories in
the left hand pane.

c. Select Role in the middle pane as the file type then click the Create button.

Configure the role:

Suffix: admin

Name: (this value is automatically created)

Description: admin role for the NeedIt application

SURESH SNOW Page 10

Click the Submit button.

Create Groups

1. Create a NeedIt Users group.

a. In the main ServiceNow browser window (not Studio), use the Application Navigator to
open User Administration > Groups.

b. Click the New button.

c. Configure the Group.

Name: NeedIt Users

Manager: System Administrator

Group email: needit.users@example.com

Description: Group for NeedIt application users

d. Click the Additional actions menu ( ) and select the Save menu item. Do not click
the Submit button because that will take you away from the form.

Add a role to the NeedIt Users group.

. In the Roles section, click the Edit… button.

a. Type x in the search field to filter the roles. Only the first 100 roles are loaded into the
slushbucket. You will not see the NeedIt roles in the slushbucket unless you filter.

b. Click the x_<your_company_code>_needit.needit_user role.

c. Click the Add button ( ) to add the role to the Roles list.

d. Click the Save button.

Add users to the NeedIt Users group.

. Switch to the Group Members section.

a. Click the Edit… button.

b. Use the slushbucket to add Beth Anglin and Zane Sulikowski to the NeedIt Users group.

c. Click the Save button.

SURESH SNOW Page 11

In the Group record, click the Update button to save the changes.

Create a NeedIt Admins group.

. In the main ServiceNow browser window (not Studio), use the Application Navigator to
open User Administration > Groups.

a. Click the New button.

b. Configure the Group.

Name: NeedIt Admins

Manager: System Administrator

Group email: needit.admins@example.com

Parent: NeedIt Users

Description: Group for NeedIt application admins

Click the Additional actions menu ( ) and select the Save menu item. Do not click the
Submit button because that will take you away from the form.

Add a role to the NeedIt Admins group.

QUESTION: There is already a role in the Roles section. Where did this role come from? If you
aren’t sure, scroll to the Answers section at the bottom of this page.

. In the Roles section, click the Edit… button.

a. Type x in the search field to filter the roles. Only the first 100 roles are loaded into the
slushbucket. You will not see the NeedIt roles in the slushbucket unless you filter.

b. Click the x_<your_company_code>_needit.admin role.

c. Click the Add button ( ) to add the x_<your_company_code>_needit.admin role to

the Roles list.

d. Click the Save button.

Add users to the NeedIt Admins group.

. Switch to the Group Members section.

a. Click the Edit… button.

SURESH SNOW Page 12

b. Use the slushbucket to add Fred Luddy and Alissa Mountjoy to the NeedIt Admins
group.

c. Click the Save button.

In the Group record, click the Update button to save the changes.

QUESTION: Why did you create the groups in the main ServiceNow browser window and not in
Studio? If you aren’t sure, scroll to the Answers section at the bottom of this page.

QUESTION: The roles from the NeedIt Users group were inherited by the NeedIt Admins group.
Were the NeedIt User group users also inherited? If you aren’t sure, scroll to the Answers section
at the bottom of this page.

Create and Modify Modules

1. Make the Open module usable only by users with the

x_<your_company_code>_needit.admin role.

a. In Studio, use the Application Explorer to open Navigation > Modules > Open for
editing.

b. In the Visibility section, click the Edit User Roles button ( ).

c. In the Selected slushbucket, click

the x_<your_company_code>_needit.needit_user role then click the Remove ( ) button.

d. In the Available slushbucket, click x_<your_company_code>_needit.admin and then

click the Add button ( ).

SURESH SNOW Page 13

e. Click the Done button to close the Roles dialog.

f. In the Module record, click the Update button to save the changes.

Make the All module visible only by users with the x_<your_company_code>_needit.admin
role.

Create a new module to dynamically display all NeedIt records for the currently logged in user.

. In Studio, click the Create Application File button.

a. In the Filter… field enter the text Module OR select Navigation from the categories in
the left hand pane.

b. Select Module in the middle pane as the file type then click the Create button.

c. Configure the module:

Title: My NeedIt Requests

Application Menu: NeedIt

Order: 150

Hint: A list of my NeedIt Requests

d. Switch to the Visibility section (tab) and click the Edit button ( ) in the Roles field.

SURESH SNOW Page 14

e. Use the slushbucket to add the x_<your_company_code>_needit.needit_user role to
the module.

f. Switch to the Link Type section (tab) and configure the options:

Link Type: List of Records

Table: NeedIt [<scope value>_needit]

Filter: [Requested for] [is (dynamic)] [Me]

Click the Submit button to save the module.

Testing

1. Configure three NeedIt requests for testing.

a. In the main ServiceNow browser window, use the Application Navigator to open NeedIt
> All.

b. Open a NeedIt record and set the Requested for value to Abel Tuter.

c. Click the Update button to save the changes.

d. Open a second NeedIt record and set the Requested for value to Beth Anglin.

e. Edit a third NeedIt record and set the Requested for value to Fred Luddy.

Examine Abel Tuter’s user record.

. In the main ServiceNow browser window, use the Application navigator to open User
Administration > Users.

SURESH SNOW Page 15

a. In the user list, click abel.tuter.

b. Scroll to the Roles section. Does Abel have any roles? Do you think Abel will be able to
see the NeedIt application and its modules?

Impersonate Abel Tuter and test his access to the NeedIt application and modules.

. In the main ServiceNow browser window, open the User menu by clicking your user
name in the ServiceNow banner. Select the Impersonate User option.

a. In the Search for user field, type Abel.

b. In the drop-down list, click abel.tuter.

c. Examine the User menu in the ServiceNow banner. You should now be Abel Tuter.

d. In the Application Navigator filter field type NeedIt. Abel should not see the NeedIt
application or modules. If you see something else, debug and re-test.

SURESH SNOW Page 16

Do you think Beth Anglin can see the NeedIt application? If so, which modules should Beth be
able to see?

. Test your prediction by impersonating beth.anglin.

a. Beth should see the NeedIt application and two modules. If you see something else,
debug and re-test.

b. Open the My NeedIt Requests module. Does Beth see only her NeedIt requests? If not,
debug and re-test.

Do you think Fred Luddy can see the NeedIt application? If so, which modules should Fred be
able to see?

. Test your prediction by impersonating fred.luddy.

a. Fred should see the NeedIt application and all four modules. If you see something else,
debug and re-test.

b. Open the All module. Can Fred see all the NeedIt records? If not, debug and re-test.

c. Open the My NeedIt Requests module. Does Fred see only his NeedIt requests? If not,
debug and re-test.

SURESH SNOW Page 17

Impersonate the System Administrator user.

Answers

Question: There is already a role in the Roles section of the NeedIt Admins group. Where did
this role come from?

Answer: The x_<your_company_code>_needit.needit_user role was inherited from the NeedIt

Users group’s. The NeedIt Users group is the parent of the NeedIt Admins group.

Question: Why did you create the groups in the main ServiceNow browser window and not in
Studio?

Answer: Groups are not application files. Groups are part of ServiceNow User administration
and not part of scoped applications. Roles, however, are scoped application files.

Question: The roles from the NeedIt Users group were inherited by the NeedIt Admins group.
Were the NeedIt User group users also inherited?

Answer: No. Roles are inheritable by a group but users are not.

Securing Table Records

Tables

When creating tables in scoped applications, you must assign a role to the table. Specify the User
role in the Controls section of the table form. You can dynamically create a new role or assign an
existing role.

For all scoped application tables, the Create access controls option is selected and is read-only.
The combination of Access Controls plus roles provide the minimum amount of security to
protect a table’s records against unauthorized access. In the default case, only users with the
table’s role can create, read, update, and delete table records.

SURESH SNOW Page 18

Access Controls

Access Controls restrict access to data by requiring users to pass a set of requirements. Access
Controls define:

 What is being secured

 The operation being secured

 The permissions required to access the object

Access Controls are automatically created when tables are added to scoped applications. The
four default Access Controls grant access to the table’s records. Permission is granted for
these operations:

 Create

 Read

 Write

 Delete

To be granted access by the default Access Controls, a user must have the User role specified for
the table.

SURESH SNOW Page 19

The default Access Controls grant permissions for entire table records; there are no default
restrictions for record fields.

ServiceNow is default deny unless configured otherwise. Permission must be explicitly granted
by Access Controls for a user to have access to records and record fields

Creating and Editing Access Controls

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 know as the security_admin role.

Elevate security privileges in the main ServiceNow browser window (not Studio). Open the User
menu in the banner and select Elevate Roles.

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

SURESH SNOW Page 20

The security_admin role times out. Depending on how long you are working on Access Controls,
you might have to elevate privileges several times.

Access Controls can be created for:

 Records

 Client callable Script Includes

 Processors

 REST Endpoints

 UI Pages

This module discusses Access Controls for records.

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.

SURESH SNOW Page 21

Table/Field

Use the Name field in the Access Control configuration to specify which records and which field
are secured. In the example, the Access Control grants write access to the NeedIt table’s
Requested for field.

The example rule is a write rule: Write: [NeedIt] [Requested for]

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 must have only
one of the roles for Requires Role to return true.

SURESH SNOW Page 22

To remove a role from the list, click the red X in the role’s row. Clicking the X removes the role
from the Access Control but does not delete the role from the database.

Condition

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

The condition is tested dynamically and the number of matching records in the database is
reported. Click the link to open a list of matching records in a new tab. Click the double arrow
icon to refresh the count.

Script

Select the Advanced option to see the Script field.

SURESH SNOW Page 23

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.

if (!gs.hasRole("admin") && !gs.hasRole("user_admin") && gs.getSession().isInteractive()) {

answer = true;

else{

answer = 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 which apply in a particular circumstance.

Recall that the NeedIt table extends the Task table.

SURESH SNOW Page 24

Due to inheritance, the Task table Access Controls can potentially grant or deny access if no
Access Controls specific to the NeedIt 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 NeedIt
table Short description field, the search order is:

1. Match the table and field name: x_58872_needit_needit.short_description

2. Match the parent table and field name: task.short_description

3. Match any table with the field name: *.short_description

4. Match the table and any field (wildcard): x_58872_needit_needit.*

5. Match the parent table and any field (wildcard): task.*

6. 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.

SURESH SNOW Page 25

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, you need to see how –None– and * work together and with other
Access Controls.

Demonstration Setup

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.

The application has two roles:

SURESH SNOW Page 26

  x_58872_generic.admin, assigned to Fred Luddy

 x_58872_generic.table_user, assigned to Beth Anglin

–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.

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

SURESH SNOW Page 27

Using this ACL, Beth can see:

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.

SURESH SNOW Page 28

Using this ACL, Fred can see:

SURESH SNOW Page 29

Using this ACL, Beth can see:

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

SURESH SNOW Page 30

 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.

Conclusions

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 *.

Debugging Access Controls

To enable Access Control debugging, use the Application Navigator in the main ServiceNow
browser window (not Studio) to open System Security > Debugging > Debug Security Rules.
The Debug Security Rules module runs a script that enables writing all Access Control
debugging information to the bottom of each page in the content frame.

Only admin users have access to the Debug Security Rules module. In most cases, Access
Controls need to be debugged for users other than the admin user. After enabling Debug Security
Rules as an admin user, impersonate a user to test their access.

In this example, Beth Anglin is denied access to Field 3 on Table in the Generic application:

The first row states the overall evaluation of the Access Control: Grant or Deny. The Access
Control is a read Access Control for Field 3.

The second row shows the evaluation of the table-level Access Control followed by the field-
level Access Control. In this case both the table-level and field-level Access Controls are shown
to make it clear which Access Control denied access.

The debugging information is shown in order of evaluation:

SURESH SNOW Page 31

It is important to examine both the color code and the symbols.

 Green: Access granted

 Red: Access denied

 Blue: The rule did not have to be re-evaluated because the result is already in the cache

 Gray: Not evaluated, typically because part of the rule has already denied access

 Check mark: Passed

 X: Failed

The system-level access check is not part of an Access Control. It runs before Access Controls
are evaluated and looks for system/runtime reasons why a user should or should not be granted
access. For example, Delegated Development grants developers permission to create only certain
types of application files. Fred might be able to create Business Rules but Beth cannot.
Permission to create application files in a Delegated Development environment is not controlled
by Access Controls and is determined at runtime by a system-level access check.

Look again at the Field 3 Access Control for Beth. Her access to Field 3 was denied by the role
on the field-level Access Control even though the table-level Access Control granted access. The
condition and script on the field-level Access Control were not evaluated because the role denied
access.

To disable Access Control debugging use the Application Navigator in the main ServiceNow
browser window to open System Security > Debugging > Stop Debugging. If you have
impersonated a user, impersonate the System Administrator to disable Access Controls.
SURESH SNOW Page 32
DEVELOPER TIP: The Admin overrides option in Access Control configuration grants access
to the admin user even if the admin user doesn’t meet the requirements of the Access Control.
Use caution when testing Access Controls as the admin user as it may not be indicative of the
Access Control’s behavior.

Debug a Single Field’s Access Controls

To debug the Access Controls for a single field rather than the entire content frame, with Debug
Security Rules enabled, open the table’s form.

A Debug icon ( ) appears next to each field. Hover over the Debug icon to see how many
Access Control messages there are for the field. Click the Debug icon to see the Access Controls
for that field. This strategy, obviously, cannot be used to debug fields that are hidden by Access
Controls.

Exercise: Access Controls

In this exercise you will create and debug Access Controls to allow NeedIt users to see only the
NeedIt records where they are the Requested for.

Preparation

1. In Studio, use the Application Explorer to open Data Model > Tables > NeedIt.

2. Copy the value in the Name field to the clipboard.

3. Impersonate Beth Anglin.

a. In the main ServiceNow browser window (not Studio), open the User menu and select
the Impersonate User option.

SURESH SNOW Page 33

b. In the Impersonate User dialog, type Beth in the Search for user field.

c. Select beth.anglin.

In the Application Navigator, type NeedIt in the Filter field. Note that Beth can see only two
modules: Create New and My NeedIt Requests. Beth cannot see the Open or All modules.

In the Application Navigator, paste the value from the clipboard and type .list at the end of the
name. It will look something like this:

Press the <return> key on the keyboard. What happens?

Typing a table name followed by .list in the Application Navigator Filter field opens the list of
table records. In the previous lab, you removed Beth’s access to the All and Open modules. If
Beth knows how to use .list, she can still see the records you didn’t intend for her to access. As
you can see, module permissions alone cannot protect a table’s records. Use Access Controls to
protect table records.

Examine Existing Access Controls

1. Impersonate the admin user.

2. Elevate Security privileges.

a. Open the User menu in the banner and select Elevate Roles.

SURESH SNOW Page 34

b. In the Elevate Roles dialog select security_admin.

c. Click the OK button.

d. If Studio was already open, you may need to reload Studio using the browser’s reload
button for Studio to detect the elevated privileges.

If the NeedIt application is not open in Studio from the last exercise, open it now.

. In the main ServiceNow browser window use the Application Navigator to open System
Applications > Studio.

a. In the Load Application dialog, click the NeedIt application.

In the Application Explorer, locate Access Controls > Access Controls.

Open the create Access Control and examine the configuration. Note the table, field (if any),
description, and the role.

Open the read, write, and delete Access Controls and examine the configurations.

QUESTION: The descriptions for the Access Controls all say Default access control. When and
how were the default Access Controls created? If you aren’t sure, scroll to the Answers section at
the bottom of this page.

Modify a Default Access Control

In this part of the exercise you will modify the default read Access Control to grant full read
access only to the application’s admin role.

SURESH SNOW Page 35

 1. In the Application Explorer, open Access Controls > Access Controls > x_<app
scope>_needit_needit (read).

2. Scroll to the Requires role section and click the Mark deleted button ( ) for the
x_<app scope>_needit.needit_user role.

3. Double-click Insert a new row….

4. Type x_ in the search field and select the x_<app scope>_needit.admin role from the
list.

5. Click the Save button ( ).

6. Click the Update button to save the changes.

Create an Access Control

In this part of the exercise you will create an Access Control to allow users with the needit_user
role to view records where they are the Requested for.

1. Create an Access Control.

a. In Studio, click the Create Application File button.

b. In the Filter… field enter the text Access OR select Access Control from the categories
in the left hand pane.

c. Select Access Control in the middle pane as the file type then click the Create button.

Configure the Access Control:

Type: record

Operation: read

SURESH SNOW Page 36

 Name: [NeedIt] [–None–]

Add the NeedIt user role to the Access Control.

. Scroll to the Requires role section and double-click Insert a new row….

a. Type x_ in the search field and select the x_<app scope>_needit.needit_user role from
the list.

b. Click the Save button ( ).

Add a condition requiring the currently logged in user to be the Requested for value.

. Scroll to the Condition section.

a. Configure the condition: [Requested for] [is (dynamic)] [Me]

Click the Submit button.

Examine the Access Control Configuration Watcher to see if other Access Controls are affected.

Click the Continue button.

Testing

1. In Studio, switch to the NeedIt table tab. If the NeedIt table tab is not still open, use the
Application Explorer to open Data Model > Tables > NeedIt.

SURESH SNOW Page 37

 2. Copy the value in the Name field to the clipboard.

3. Impersonate Beth Anglin.

4. In the Application Navigator, paste the value from the clipboard and type .list at the end
of the name.

5. Press the <return> key on the keyboard. You should see something like this. The total
number of records and number of records removed will vary depending on the records in
your instance.

6. Open one of the records from the list and verify that Beth is the Requested for. If not,
debug and re-test.

7. Impersonate Fred Luddy.

8. In the Application Navigator filter field paste the value from the clipboard followed by
.list. Press the <enter> key.

9. Fred should be able to see all the NeedIt request records without constraint. If not, debug
and re-test.

10. Impersonate the System Administrator.

Answers

SURESH SNOW Page 38

Question: The descriptions for the Access Controls all say Default access control. When and
how were the default Access Controls created?

Answer: In scoped applications, creating a table also creates a set of four Access Controls:
create, read, write, and delete.

Scripting Security
Both the client-side and server-side APIs have methods for scripting security.

The client-side GlideUser (g_user) API has these methods:

 hasRole()

 hasRoleExactly()

 hasRoleFromList()

 hasRoles()

The client-side API methods can be used in any client-side script such as Client Scripts and UI
Policy scripts. Client-side security is the easiest security to break. Do not depend on client-side
scripts to secure sensitive data.

The server-side GlideSystem (gs) API has these methods:

 getUser()

 getUserID()

 getUserName()

 hasRole()

 isLoggedIn()

 isInteractive()

 getSession()

The server-side GlideElement API has methods to check whether a user’s role allows them to
access the associated GlideRecord(s):

 canCreate()
SURESH SNOW Page 39
  canRead()

 canWrite()

The server-side methods can be used in any server-side script such as Business Rules or Script
Includes. Server-side scripted security is more secure than client-side scripted security. Any user
with access to scripting fields can see the scripts and see what the security checks are.

Neither client-side nor server-side scripts are part of the Debug Security Rules module. When
security is scripted outside of Access Controls, it must be debugged independently of the Access
Controls.

For the highest level of security, use Access Controls to protect sensitive data.

SURESH SNOW Page 40