While developing a scoped application, you may want to secure scoped applications against other applications. Securing application helps the author to have control of their application and prevents customers from interacting with any other artifacts without the author's knowledge. Below are the ways in which design time permissions on the scoped application can be granted or restricted.

 

3 ways to secure your application

  1. Application Access Setting
  2. Cross Scope Access
  3. Restrict Table Choices

 

In this post, I will show you how to utilize Cross Scope Access, Application access setting and Restrict Table Choices to secure your scoped apps against other applications. I'll give you examples of how to use Application Access Setting, Restrict Table Choices, Cross Scope Access to enable access, disable access, and track your scoped apps across the platform.

 

Application Access Setting

Application Access Setting is defined to specify what application artifacts are available to other custom applications in different application scopes. These permissions are in addition to the standard access controls (ACLs) that determine whether users can access data in the custom application.

 

  1. On your instance navigate to System Applications > Studio
  2. Click on open Studio tab.
  3. Click on the application and then select the tables whose application access setting needs to be modified. You will see the below image once you click on any table.

scoped application access.jpg

The Can read, Can write, Can update, and Can delete Application Access options, grant scripts from other application scopes the ability to perform database operations against the table records. In the default case, all application scope scripts can read the table’s records but cannot perform any other database operations.

 

 

"Allow configuration" restricts whether out-of-scope applications can create application files like Business rules, New fields, Client script and UI actions.

 

Restrict application on a scoped app

I can restrict other applications from doing any operation (Create, Read, Update, Delete, Web Service Interaction) on this scoped app by selecting the "Accessible from" value to “This application scope only.” Other application can only interact when the value is set to  "All application scopes.” Depending on the requirement and the use case, you can select all or either on this checkbox to grant permission for other applications.

 

For other artifacts like Script Include, access is granted or restricted depending on the value set on “Accessible from” field. This field defines whether a script is public or private.

 

Making a script public

A public script is a script available to all applications. To make a script public, set the "accessible from" field on the Script Include  to all application scopes. Any changes to a public script include must be done carefully to prevent breaking applications that depend on it.

 

Making a script private

A private script is a script which is specific to the application which it is defined.To make a script private and inaccessible from other applications, set the "Accessible from" field to This application scope only. This allows the script to be called only by code within the defined application scope and prevents code in other application scopes from accessing the script. By setting scripts to private, application developers can easily modify or refactor scripts in future versions since no other applications depend on it.

 

Example of creating a Record in a Group Table:

 

Application access settings are different on each OOTB tables. For example, the default Group table allows another application scope Web Service access and Read access. However, other permissions are restricted. If a script attempts to perform an operation that is not allowed, admin users see a message:

Execute operation on API 'GlideRecord.insert' from scope 'CSA' was denied. The application 'CSA' must declare a cross scope access privilege. Please contact the application author to update their privilege requests.

Evaluator: com.glide.script.fencing.CrossScopeAccessNotAllowedException: Access to GlideRecord.insert from scope x_13241_csa not allowed

In the above case, "Can Create" checkbox has to be set to true to be able to create the records in Group table.

 

 

Example of making a call to JSUtill from a scoped application:

 

In the below screenshot we can see JSUtil cannot be called from any other application as the accessible value OOTB is set to "This application scope only".

jsutill scoped app.jpg

In the above case, accessible from has to be changed to "All application scope" to ensure JSUtill works across applications.

 

Please be aware any changes made on global artifacts will be in the global update set.

 

Please work out with ServiceNow Certification Team in case you have modified the application access setting (Global or base system tables) and the app is intended to be submitted to store. We will approve or reject apps on the store based on the application use case. The same case applies to any modification made (Accessible From value) on base system artifacts like script include.

Cross Scope Access

Cross scope access allows administrators to manage out-of-scope access to application resources by creating a list of operations and runtime privileges that the application authorizes to run on the target instance. A cross scope is applicable only if the author of the app sets the Runtime access value to Tracking or Enforcing. This helps the author to have control on their application and prevents customers from interacting with any other artifacts without the author's knowledge once the app is downloaded on the target instances.

 

Cross-scope privileges can be granted for:

  • Table: Read, write, create, delete records
  • Script Include: Execute API
  • Scriptable (script objects): Execute API

 

Enabling Cross Scope Access

  1. On your instance navigate to System Applications > Studio
  2. Click on application i.e for ex : CSA ( This is the custom application I have created on my instance)

    create scope access.jpg

  3. Open the File menu and select the Settings menu item. The default value for the Runtime Access Tracking field is set to Tracking.

    scoped app tracking.jpg

 

  • None: All cross scope privileges are granted automatically at runtime.
  • Tracking: Allows application scripts to access resources from other applications. A record for the access is automatically inserted in the cross-scope access table with a Status value of Allowed. This is the default setting.
  • Enforcing: Allows application scripts to access resources from other applications only after an admin authorizes the access. A record is automatically added to the cross-scope access table with a Status value of Requested.

 

A custom application which have "runtime access " set to tracking will be changed to enforced automatically during app installation on the target instance.

 

During testing, application developers should run all of their application scripting logic to ensure the system creates any necessary cross-scope privilege records. After application publication, the system only allows runtime requests to run that have a valid cross-scope privilege record.

 

Example of across access scoped application:

 

Let’s assume I have a business rule on the custom table which creates a record on Incident table. To make this app work on other instance, I as an author should ensure that this script is at least once executed on my dev instance. You will see an entry in cross scope table as soon as this script is executed on dev instance before the app is published.

 

Here we are assuming Runtime Access Tracking is set to Enforcing.

var gr = new GlideRecord('incident');
gr.initialize();
gr.short_description = 'This is a test for CSA';
gr.insert();

 

When the script executes, ServiceNow checks to see if the cross-scope access between the CSA scope and the Global scope table is allowed. In this case, it is not because the Enforcing setting requires an admin to authorize the access. This is a snippet of the error from the System Log:

Security restricted: Execute operation on API 'GlideRecord.insert' from scope 'CSA' was denied. The application 'CSA' must declare a cross scope access privilege. Please contact the application author to update their privilege requests.

Evaluator: com.glide.script.fencing.CrossScopeAccessNotAllowedException: Access to GlideRecord.insert from scope x_13241_csa not allowed

 

  1. Open the Application Cross-Scope Access module by navigating to System Application> Application Cross-Scope Access
  2. Search for all records with a Status field value of Requested
  3. To grant access, an admin user must click the Open record icon to open the record for editing.
  4. Change the Status to Allowed then click the Update button.

access cross scope app.jpg

The above case is only when the author chose to set runtime access to enforcing. By default, runtime access is set to tracking on the application and at runtime, cross scope privilege records are automatically granted access.

 

 

Restrict Table Choices in a scoped application

To get to Restrict Table Choices, follow the same steps 1, 2 and 3 as mentioned in cross scope section above. Restrict Table Choices application sets limits on an application file configuration to only tables from the current application. This setting can be defined at each application level. By default, the checkbox is set to false. You can set the value to true depending on your app requirements.

 

Example of restricting table choices:

 

Let’s assume I have set Restrict table choice checkbox to true. In that case, we can only select tables which are in the same scope. This will be true for any artifact created in scoped app for ex: Client script, UI Policy Etc.

restrict table choices.jpg

 

We have successfully covered how Cross Access Tracking manages out-of-scope access to application resources, Application Access restricts database operations, and Restrict Table Choices application to limit application files configuration. Utilizing Cross Scope and Application Access Setting are key components of scoped applications and its success.

 

For additional help on this topic, see what other customers have asked:

cross scope privileges denied by table cross scope

Cross scope privilege issue in Scoped Application

access to api refused

Scoped apps - can I allow scripted read access to global scope without allowing creation of business rules, too?