The Now Platform® Washington DC release is live. Watch now!
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
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 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.
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.
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.
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.
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".
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 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:
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
|
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.
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.
|
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
Additional Resource :
https://servicenowben.wordpress.com/2018/09/27/cross-scope-privileges/ By my good friend Ben Philips
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.