Washington DC Platform Security 4-20-2024

Washington DC Platform security
Washington DC Platform
security
Last updated: April 20, 2024
PDF generated on April 20, 2024

©2024 ServiceNow. All rights reserved. Terms of Use Privacy Statement
ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in
the United States and/or other countries. Other company and product names may be trademarks of the respective companies with which
they are associated.
Some examples and graphics depicted herein are provided for

illustration only. No real association or connection to ServiceNow
products or services is intended or should be inferred.
This PDF was created from content on docs.servicenow.com. The web
site is updated frequently. For the most current ServiceNow product
documentation, go to docs.servicenow.com.
Company Headquarters
2225 Lawson Lane
Santa Clara, CA 95054
United States
(408)501-8550
PDF generated on April 20, 2024 2

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the
United States and/or other countries. Other company and product names may be trademarks of the respective companies with which they are
associated.
Access Control List Rules

Rules for access control lists (ACLs) restrict access to data by requiring
users to pass a set of requirements before they can interact with it.
Explore Learn about Configure

ACL.
Configure ACL.
Reference
Advanced
Get details about Contextual
Security Manager. Learn more about Advanced ACL.
Exploring Access Control Lists

Explore Access Control Lists (ACL).
Components of ACLs
All access control list rules specify:
• The object and operation being secured
• The permissions required to access the object

associated.
The object is the target to which access needs to be controlled. Each

object consists of a type and name that uniquely identifies a particular
table, field, or record.
For example, all these entries specify an object:
Type Name Object secured
record [incident].[--None--] The Incident table.
The Active field in the

record [incident].[active]
Incident table.
The record for the

REST_Endpoint user_role_inheritance user_role_inheritance
Scripted REST API.
Each operation describes a valid action the system can take on

the specified object. Some objects, such as records, support multiple
operations, while other objects, such as a REST_Endpoint, only support
one operation.
For example, all these entries specify an operation:
Type Name Operation Operation secured
Creating
[incident].[--
record create records in the
None --]
Incident table.
Updating the
[incident]. Active field in
record write
[active] the Incident
table.
Running the
user_role_inherit user_role_inherit
REST_Endpoint execute
ance ance scripted
REST API.

associated.
The permissions specify when someone can access the named

object and operation. Security administrators can specify permission
requirements by adding:
• One or more user roles to the Requires role list.
• One or more conditions.
• A script that evaluates to true or false or sets the answer variable to

true or false.
To gain access to an object and operation, a user must pass all

permissions listed in an access control. For example, this access control
restricts access to view operations on the incident table.
To update a record in the incident table, a user must have the listed roles
and the record must meet the condition.

associated.
Permission type Requirement Description
Only allow users with

Requires role Requires role:itil the itil role to update
incidents.
Only allow updates

[Incident state] [is not]
Condition to active incident
[Closed]
records.
ACL evaluation process
An ACL rule only grants a user access to an object if the user meets all
permissions required by the matching ACL rule.
• The condition must evaluate to true.
• The script must evaluate to true or return an answer variable with the
value of true.
• The user must have one of the roles in the required roles list. If the list is
empty, this condition evaluates to true.
• [Record ACL rules only] The matching table-level and field-level ACL
rules must both evaluate to true.

associated.
ACL evaluate permissions
Whenever a session requests data, the system searches for access

control rules that match the requested object and operation. If there’s
a matching access control rule, then the system evaluates if the user has
the permissions required to access the object and operation. If an access
control rule specifies more than one permission, then the user must meet
all permissions to gain access to the object and operation. Failing any

associated.
one permission check prevents the user from accessing the matching
object and operation.
If a user does not meet the permissions of the first matching rule, the
system evaluates the permissions of the next matching access control
rule as specified by the access control processing order. If the user fails
to meet the permissions of any matching access control rule, the system
denies access to the requested object and operation.
Note: If there are no matching access control rules for the
requested object and operation, then the system grants the user
access to it. In practice, it is rare for the system to find no matching
rules because the system has a set of default access control rules
that protect all record operations.
The effects of being denied access to an object depend on the ACL

rule that the user failed. For example, failing a read operation ACL rule
prevents the user from seeing the object. Depending on the object
secured, the ACL rule hides a field on a form, hides rows from a list, or
prevents a user from accessing a UI page. The following table contains
a complete list of results of failing an ACL rule for a given operation and
object type.
Pre and post query ACL checks

Your instance checks ACL rules both before and after a user makes
a query. Because different information is available before and after a
query, results can be different.
Pre-query ACL check
Before your instance runs a database query, it checks the ACL rules for
each field in the queried table to determine which fields a user may
access. This check only looks at the user's roles, and checks to see if these
roles allow access to fields. Because this check runs before the query, the
ACL doesn't have access to the records on the table, so it can’t take
that data into account. Scripts and conditions that rely on knowing the
contents of a record aren’t evaluated.
If the user doesn't have read access at this point, the value for the field
isn’t shown to the user.

associated.
Post-query ACL check
After the query, your instance checks each record returned by the query.
During this check, there’s context for the ACL, so the role, condition,
and script portions of the ACL are evaluated. If the user doesn't have
read access at this point, the value for the field isn’t shown to the user,
however the user sees the field label if their roles allow access to the field.
Operation Results of failing an ACL rule on object
User can’t execute scripts on a

execute
record or UI page.
User can’t see the New UI action

from forms. The user also cannot
insert records into a table using API
protocols such as web services.
A create ACL with a condition

create
requiring that a field contain a
specific value always evaluates as
false. Fields on new records are
considered empty until the record
is saved.
User can’t see the object in forms

or lists. The user also can’t retrieve
read
records using API protocols such as
web services.
User sees a read-only field in

forms and lists, and the user can’t
write
update records using API protocols
such as web services.
User cannot see the Delete UI

action from forms. The user also
delete can’t remove records from a table
using API protocols such as web
services.

associated.
Operation Results of failing an ACL rule on object
User cannot define relationships

edit_task_relations
between task tables.
User cannot define relationships

edit_ci_relations between Configuration Item
[cmdb_ci] tables.
Used to control the fields that

save_as_template should be saved when a template
is created.
User can’t view or personalize

add_to_list specific columns in the list
mechanic.
User can’t update records (rows)

list_edit
from a list.
User can’t create a report on the

ACL table. For more information,
report_on
see Restrict report creation with an
ACL rule.
User can’t view the content of a

report on the ACL table or on the
report_view
ACL field. For more information,
see Reporting.
User can’t right-click a list field and

personalize_choices
select Configure Choices.
ACL matching requirements for objects
Matching ACL Rules

Existing wild-card ACL
Object Type Required to Access
Rules
Object
Client-callable script Users must meet the By default, there are

includes permissions of two ACL no wild-card (*) rules
rules: for these object types.

associated.
Matching ACL Rules

Existing wild-card ACL
Object Type Required to Access
Rules
Object
1. All wild-card ACL
rules for the object
(if any ACL rule
exists for the If you create a wild-
operation). card ACL rule for one
Processors of these objects, then
2. The first ACL rule
the ACL rule applies to
that matches the
all objects of this type.
object's name (if
any ACL rule exists
for the operation).
UI pages Users must meet the By default, there

permissions of two ACL are wild-card table
rules: rules (*) for the
create, read, write,
1. The first ACL rule and delete operations
that matches the and wild-card field
record's field (if rules (*.*) for the
any ACL rule exists personalize_choices,
for the operation). create, and
Record
save_as_template
2. The first ACL rule operations. When you
that matches the create a table, create
record's table (if ACL rules for the table
any ACL rule exists unless you want to use
for the operation). the provided wild-card
ACL rules.
Note: The Security manager default behavior

(glide.sm.default_mode) property determines whether users can
access objects that only match against wild-card table ACL rules.
When this property is set to Deny access, only administrators can
access objects that match the wild-card table ACL rules.

associated.
Note: The wild-card field ACL rule (*.*) for the create operation
reuses the same permissions as the write operation. This means that
the create permissions are the same as the write permissions unless
you define an explicit create operation ACL rule.
Multiple ACL rules at the same point in the processing order
If two or more rules match at the same point in the processing order, the
user must pass any one of the ACL rules permissions to access the object.
For example, if you create two field ACL rules for incident.number, then
a user who passes one rule has access to the number field regardless of
whether the user failed any other field ACL rule at the same point in the
processing order.
Required role
Normal admin users can view and debug access control rules. However,
to create or update existing access control rules, administrators must
elevate privileges to the security_admin role. See Elevate to a privileged
role for instructions.
ACL rules in scoped applications
You can create ACL rules for objects in the same scope as the ACL rule.
You can also create ACL rules for tables with at least one field that is in
the same scope as the ACL rule.
For tables that are in a different scope than the ACL rule record, the
types of rules are limited.
• You can create an ACL rule for any table, UI page, or other object that
is in the same scope as the ACL rule.
• You can create an ACL for a field that is in the same scope as the ACL
rule.
• If the table is in the same scope, you can use a script to evaluate
permissions.
• If the table is in a different scope, you can’t use a script to evaluate

permissions.

associated.
• You can’t create or modify ACL rules for objects that are in a different
scope than the application you’ve selected in the application picker,
including adding a role to an ACL in a different scope.
• You can create wild-card table rules (*) only in the global scope.
• You can create wild-card field rules (*) only for tables in the same
scope as the ACL rule.
ACL rule types

Create ACL rules on different components of the system.
Record ACL rules
Record ACL rules consist of table and field names.
• The table name is the table that you want to secure. If other tables
extend from this table, then the table is considered a parent table. ACL
rules for parent tables apply to any table that extends the parent table.
• The field name is the field that you want to secure. Some fields are part
of multiple tables because of table extension. ACL rules for fields in a
parent table apply to any table that extends the parent table.
ACL rules can secure the following record operations:
Operation Description
Enables users to insert new records

create
(rows) into a table.
Enables users to display records

read
from a table.
Enables users to update records in

write
a table.
Enables users to remove records

delete
from a table or drop a table.

associated.
Enables users to extend the Task

edit_task_relations
[task] table.
Enables users to extend the

edit_ci_relations Configuration Item [cmdb_ci]
table.
Enables users to save a record as a

save_as_template
template.
Prevents users from viewing or

personalizing specific columns in
the list mechanic.
add_to_list
Note: Conditions and scripts
are not supported.
Enables users to update records

list_edit
(rows) from a list.
report_on Enables users to report on tables.
Enables users to report on field

report_view
ACLs.
Enables users to configure the

personalize_choices
table or field.
Record ACL rules are processed in the following order:
• Match the object against table ACL rules.
• Match the object against field ACL rules.
This processing order ensures that users gain access to more specific
objects before gaining access to more general objects. A user must pass
both table and field ACL rules to access a record object.
• If a user fails a table ACL rule, the user is denied access to all fields in
the table, even if the user passes a field ACL rule.

associated.
• If a user passes a table ACL rule, but fails a field ACL rule, the user
cannot access the field described by the field ACL rule.
ACL matching
Processor ACL rules
Processor ACL rules specify the processor you want to secure. For a list of
available processors, navigate to System Definition > Processors.
By default, an ACL rule for the EmailClientProcessor is included to restrict

the email client to users with the itil role.
Processor ACL rules honor the STAR (*) rule if they cannot find a more
specific ACL for those resources.

associated.
Table ACL rules
The user must first pass the table ACL rule. Since the base system includes
STAR (*) table ACL rules that match every table, the user must always
pass at least one table ACL rule. The base system provides additional
table ACL rules to control access to specific tables.
Table ACL rules are processed in the following order:
1. Match the table name. For example, incident.
2. Match the parent table name. For example, task.
3. Match any table name (*). For example, *.
If a user fails all table ACL rules, the user cannot access any fields in the
table. If a user passes a table ACL rule, the system then evaluates the
field ACL rules.
Field ACL rules

After a user passes a table ACL rule, field ACL rules are processed in the
following order:
1. Match the table and field name. For example, incident.number.
2. Match the parent table and field name. For example, task.number.
3. Match any table (*) and field name. For example, *.number.
4. Match the table and any field (*). For example, incident.*.
5. Match the parent table and any field (*). For example, task.*.
6. Match any table (*) and any field (*). For example, *.*.
A user must pass the table ACL rule to be granted access to the table's
fields. For example, the user must first pass the table ACL rule for the
incident table to access the Number field in the incident table.
The first successful field ACL evaluation stops ACL rule processing at
the field level. When a user passes a field ACL rule, the system stops
searching for other matching field ACL rules. For example, if a user passes
the field ACL rule for incident.number, the system stops searching for
other ACL rules that secure the Number field in the incident table.

associated.
Access to query information of inferred data is restricted for protected

fields, therefore preventing return of predictive information.
UI page ACL rules
UI page ACL rules specify the UI page to be secured. For a list of

available UI pages, navigate to System UI > UI Pages. When defining an
ACL rule for a UI page, use the fully scoped page name. For example,
x_myapp_mypage.
Note: You can use the STAR (*) character in the Name field on
ui_page type ACLs to match any UI pages.
UI page ACL rules honor the STAR (*) rule if they cannot find a more
specific ACL for those resources. For example, if you have a UI page
named mysecretpage but do not define an ACL for this UI page, the
STAR (*) rule for the UI page processor is used for access check.
ACL rules can secure the following UI page operation:
read Allows users to display the UI page.
Client-callable script include ACL rules
Script include ACL rules specify the client-callable script include to

be secured. For a list of available script includes, navigate to System
Definition > Script Includes. You can personalize the list to show the Client
callable column.
The base system does not include any ACL rules for client-callable script
includes.
Client-callable script include ACL rules honor the STAR (*) rule if they
cannot find a more specific ACL for those resources.
ACL control of function fields

When evaluating access to a function field, in addition to checking
access to the function field itself, the system also checks access to the

associated.
function's contributing fields. Contributing fields are those used as the

arguments in a given function definition.
For more information about function fields, see Function field.
In Rome and earlier, the system simply checks access to the function
field itself (as with any other field). If the ACLs on that field allow access,
the user receives the resulting value, regardless of whether the user has
access to the contributing fields.
In Washington DC and later, the system also requires access to all

contributing fields in order to allow access to the function field. If one
or more of the contributing field ACLs refuse access, the function field
also refuses access.
The only operations affected by the new requirement are read and
report_view. Report_view has its own additional requirements.
A user has read access to a

function field only if both of the
following are true:
• The user has read access to the

read operation function field.
• The user has read access to all of

the contributing fields used in the
function.
A user has report_view access to

a function field only if all of the
following are true:
report_view operation • The user has report_view access

to the function field.
• The user has report_view access

to each of the contributing fields.

associated.
• There is a role-only read ACL
without conditions and without a
script, and the user has that role.
• The user has role-only read

access to the contributing fields,
such that only ACLs without
condition or script can allow.
Examples
Given:
• Table: salary
• Columns: base, bonus, total (all are Integers in this example)
• Function field: The total column is marked as a function field, with

function definition glidefunction:add(base, bonus).
• Contributing fields: base and bonus, since they're used in the function
definition
• Roles: salary_admin, bonus_admin
Example 1: All fields allow access
ACLs Result
A user with the salary_admin role

total, base, bonus: read and
is granted read and report_view
report_view for role salary_admin,
access to total because they have
with no conditions or scripts
the required role.
Example 2: Contributing field refuses read access
ACLs Result
A user with the salary_admin role

• total, base: read and
is refused read and report_view
report_view for role

associated.
ACLs Result
salary_admin, with no conditions
or scripts
• bonus: report_view for role

salary_admin , with no conditions
access to total, because bonus
or scripts
refuses read access to their role.
• bonus: read for role
bonus_admin, with no conditions
or scripts
Example 3: Contributing field ACL has script
ACLs Result
• total, base: read and A user with the salary_admin role

report_view for role is granted read access to total,
salary_admin, with no conditions because they have the required
or scripts role for all fields.
• bonus: report_view for role But the same user with

bonus_admin, with no conditions the salary_admin is refused
or scripts report_view access, because the
read ACL with the script refuses
• bonus: read for role access by default for this case,
salary_admin, with a script (note even though they have the
that it doesn't matter what's in required role.
the script, only that it's there)
Security jump-start - ACL rules plugin

The Security jump-start access control level (ACL Rules) plugin is installed
automatically on all new instances. Use this plugin to quickly secure
multiple system tables and expedite the production launch process for
your organization.
This plugin isn’t intended for existing instances, as it may alter security
access to tables already in use in a production environment. If an
admin strongly desires to install this plugin on an existing instance, it's

associated.
recommended to test it thoroughly in a test instance first. Doing so helps

to ensure compatibility with the organization's current implementation.
If an admin is interested in the new ACL rules provided by this plugin, they
can manually create one or more in an existing instance, using the list of
ACLs as a guideline.
The following ACLs are included in this plugin. Select the icon in a header
row to sort that column in ascending or descending order. The Operation
key is as follows:
• R=read
• W=write
• D=delete
• C=create
Name Operation Description
asset or itil
role required to
cmdb_ci WCD write/create/delete
Configuration Item
records
user_admin role
required to write/
cmn_department WD
delete Department
records
user_admin role
required to write/
cmn_location WC
create Location
records
user_admin role
required to write/
core_company WD
delete Company
records

associated.
knowledge role
kb_knowledge create required to create
Knowledge records
user_admin role
required to read/
ldap_ou_config RWCD write/create/delete
LDAP OU Definition
records
user_admin role
required to read/
ldap_server_config RWCD
write/create/delete
LDAP Server records
admin role required

process_guide WCD to write/create/delete
Process Guide records
admin role required

process_step WCD to write/create/delete
Process Step records
catalog_admin role
required to create
sc_category create
Service Catalog
Category records
catalog_admin role
required to delete
sc_category delete
Service Catalog
Category records
catalog_admin role
required to write
sc_category write
to Service Catalog
Category records

associated.
catalog_admin role
sc_cat_item write required to write to
Catalog Item records
catalog_admin role
sc_cat_item delete required to delete
catalog_admin role
sc_cat_item create required to create
all users can read

sysevent_email_act Email Notification
read
ion records (for
subscription purposes)
admin role required

to read/write/create/
sysevent_register RWCD
delete Event Registry
records
admin role required

sysevent_script_ac to read/write/create/
RWCD
tion delete Script Action
records
admin required
syslog RWCD
delete Log Entry
records
admin required
delete Rule records
sysrule RWCD (Email Notifications,
Inbound Email Actions,
Approval Rules, and so
on)

associated.
all users can read

Email Notification
sysrule read records for
(subscription-based
notifications)
admin required to
sys_app_applicatio
WCD write/create/delete
n
Application records
admin role required

to write/create/delete
sys_app_category WCD
Application Category
records
admin required to
sys_app_module WCD write/create/delete
Module records
admin required
sys_audit RWCD to read/write/create/
delete Audit records
personalize_dictionary
role required to
sys_dictionary RWC
read/write/create
Dictionary records
sys_dictionary.* read role can read
Dictionary fields
sys_documentation delete role required to delete
Field Label records
sys_documentation create role required to create
Field Label records

associated.
sys_documentation write role required to write
to Field Label records
admin role required

sys_gauge RWCD to read/write/create/
delete Gauge records
admin role required

sys_gauge_count RWCD
delete Gauge Count
records
itil role required to see

sys_group_has_role read
Group Role records
itil_admin role required

sys_home WCD
Welcome Page
Section records
admin role required

sys_installation_e
WCD to write/create/delete
xit
Installation Exit records
admin role required

sys_job WCD to write/create/delete
Sys Job records
admin role required

sys_nav_link WCD
Navigation Link
records
admin role required

sys_perspective WCD to write/create/delete
Menu List records

associated.
admin role required

sys_portal RWCD to read/write/create/
delete Portal records
admin role required

sys_portal_page RWCD
delete Homepage
records
admin role required

sys_portal_prefere to read/write/create/
RWCD
nces delete Portal
Preferences records
admin role required to

sys_processor WC write/create Processor
records
admin role required

sys_properties WC to write/create System
Property records
admin role required

sys_properties_cat to write/create/delete
WCD
egory Property Category
records
roles that can

delete Report records
sys_report delete (doesn’t restrict
deleting through
Report UI)
roles that can write

to Report records
sys_report write
(doesn’t restrict editing
through Report UI)
users can read

sys_report read their own Report
records, those of

associated.

their groups, and
GLOBAL ones (doesn’t
affect viewing through
Report UI)
roles that can

read Report records
sys_report read (doesn’t restrict
viewing through
Report UI)
admin role required

sys_reportroles read to read Report Roles
records
admin role required

sys_script WCD to write/create/delete
Business Rule records
admin role required

sys_script_ajax WCD to write/create/delete
AJAX Script records
admin role required

sys_script_client WCD to write/create/delete
Client Script records
admin role required

sys_script_include WCD to write/create/delete
Script Include records
admin role required

sys_security_acl write to write to Access
Control records

sys_security_acl_role create create Access Roles
records

associated.

sys_security_acl_r
delete delete Access Roles
ole
records

sys_security_acl_r
write write to Access Roles
ole
records
admin role required

sys_security_opera
delete to delete Security
tion
Operation records
admin role required

sys_security_opera
create to create Security
tion
Operation records
admin role required

sys_security_opera
write to write to Security
tion
Operation records

sys_security_type write write to Security Type
records

sys_security_type create create Security Type
records

sys_security_type delete delete Security Type
records

sys_status create create System Status
records

sys_status delete delete System Status
records

associated.

sys_status write write to System Status
records
template_editor role
sys_template write required to write to
Template records
emplate_editor role
sys_template create required to create
Template records
sys_template delete required to delete
Template records
required to read
sys_template read
Template Roles
records
admin role required

sys_ui_action create to create UI action
records
admin role required

sys_ui_action delete to delete UI action
records
admin role required

sys_ui_action write to write to UI action
records

sys_ui_action_view write write to UI View Action
records

sys_ui_action_view create create UI View Action
records

associated.

sys_ui_action_view delete delete UI View Action
records
admin role required

sys_ui_policy create to create UI Policy
records
admin role required

sys_ui_policy delete to delete UI Policy
records
admin role required

sys_ui_policy write to write to UI Policy
records

sys_ui_policy_acti
create create UI Policy Action
on
records

sys_ui_policy_acti
delete delete UI Policy Action
on
records
admin role required

sys_ui_policy_acti
write to write to UI Policy
on
Action records
admin role required

sys_ui_script write to write to UI Script
records
admin role required

sys_ui_script delete to delete UI Script
records
admin role required

sys_ui_script create to create UI Script
records

associated.
Users with no role

sys_user write can’t update any user
record but their own
user_admin role
required to delete
sys_user_grmember delete
Group Member
records
user_admin role
required to write
sys_user_grmember write
to Group Member
records
Only itil and above

sys_user_group create can create group
records
Only itil and above

sys_user_group write can write to group
records
itil role required to see

sys_user_has_role read
User Role records

sys_user_role create
create Role records

sys_user_role delete
delete Role records

sys_user_role write
write to Role records
itil role required to

sys_user_role_cont
read see Contained Role
ains
records

associated.
admin role required

sys_user_role_cont
write to write to Contained
ains
Role records
admin role required

sys_user_token RWCD
delete User Token
records
Note: To learn more about this plugin, see Security jump start (ACL
rules) (instance security hardening) in Instance Security Hardening
Settings.
Configuring an ACL rule

Configure a custom ACL rule to secure access to new objects or to
change the default security behavior.
Before you begin
Role required: security_admin
About this task
To create ACL rules, you must elevate privileges to the security_admin

role.
For tables that are in a different scope from the ACL rule
record, the types of rules are limited. For Scope Master
tables to derive scope and execute scoped ACLS, set the
glide.enforce_security_scope.<scope_name> property to true. This
ensures ACLs in the global scope do not match when there are scope
specific ACLs created on the relevant table. Examples are when securing
data within shared application tables in the Global scope, such as
sys_attachment or sys_question_answer tables.
Procedure
1. Elevated privilege roles to the security_admin role.

associated.
2. Navigate to System Security > Access Control (ACL).
3. Click New.
4. Complete the form.

Access control fields
Field Description
Select what kind of object

this ACL rule secures. The type
of object determines how the
object is named and what
operations are available. This
Type
field becomes read only after
the ACL rule is created. If you
want to change the type, you
must delete the ACL and create
a new one with the correct type.
Select the operation this ACL

rule secures. Each object type
has its own list of operations. An
Operation ACL rule can only secure one
operation. To secure multiple
operations, create a separate
ACL rule for each.
Select this check box to

have users with the admin
role automatically pass the
permissions check for this ACL
rule. Admin users pass regardless
of what script or role restrictions
Admin overrides apply. However, the nobody
role, which only ServiceNow
personnel can assign, takes
precedence over the admin
override option. If an ACL
is assigned the nobody role,
admin users cannot access the
resource even when Admin

associated.
Field Description
overrides is selected. See Base
system roles.
Clear this check box if

administrators must meet the
permissions defined in this
ACL rule to gain access to
the secured object. Since
administrators always pass role
checks (see the description of
the Requires role field), use the
condition builder or Script field to
create a permissions check that
administrators must pass.
Select this check box to enforce

Active
this ACL rule.
Select this check box to display

the Script field.
Important: If there is script
Advanced
in the Script field. This script
executes even if the field is
not displayed on the form.
Enter the name of the object

being secured, either the record
name or the table and field
names. The more specific the
name, the more specific the ACL
rule. You can use the wildcard
character asterisk (*) in place of
Name
a record, table, or field name
to select all objects that match
a record type, all tables, or
all fields. You cannot combine
a wildcard character and a
text search. For example, inc*
is not a valid ACL rule name,

associated.
Field Description
but incident.* and *.number are
valid ACL rule names.
Note: Click the blue
triangle to manually enter
the record name or the
table and field names of
the object being secured.
Use this option to secure an
object that does not appear
in the dropdown.
Enter a description of the object

Description or permissions this ACL rule
secures.
Use this list to specify the roles

a user must have to access the
object. If you list multiple roles, a
user with any one of the listed
roles can access the object. The
Requires role list appears as a
related list.
Requires role
Note: Users with the
admin role always pass
this permissions check
because the admin role
automatically grants users
all other roles.
Use this condition builder to

select the fields and values that
Condition
must be true for users to access
the object.
Enter a custom script describing

the permissions required to
Script access the object. The script can
use the values of the current
and previous Global variables

associated.
Field Description
in business rules as well as
system properties. The script must
generate a true or false response
in one of two ways:
• return an answer variable set

to a value of true or false
• evaluate to true or false
In either case, users only gain

access to the object when the
script evaluates to true and the
user meets any conditions the
ACL rule has. Both the conditions
and the script must evaluate to
true for a user to access the
object.
Note: If the evaluated

item is in a related list,
current points to the item
the related list is on, not to
the current item the ACL is
for. However, If the item you
are evaluating the ACL for is
not in a related list, current
points to the actual item.
5. Right-click the form header and select Save.
Secure records in an embedded list
To apply security to the records in embedded lists, limit editing and

deleting records in embedded lists to specific roles.
Before you begin

associated.
Procedure
1. Navigate to All > System Security > Access Control (ACL).
2. Open the Write or Delete record for the appropriate table.
3. In the Requires Role section of the form, add the roles that have write
or delete permission for that table.
4. Save the changes.

When records from the associated table appear in an embedded
list, the edit and delete options are available only to users with the
specified roles.
Contextual Security Manager

Contextual Security Manager protects your data by controlling read,
write, create, and delete authorization.
Key advantages
The Contextual Security Manager is aware of the system table hierarchy,

enabling you to create specific security rules for a field based on
where in the hierarchy it is displayed. Benefits of the Contextual Security
Manager include:
• Contextual security: Secure a record based on the contents of the

record.
• Hierarchical security: Apply security rules to any level in the object

hierarchy.
Securing fields and tables
With the legacy Simple Security Manager, you could secure fields and
tables by adding roles to the appropriate dictionary entry. With the
Contextual Security Manager, these dictionary roles are no longer tested.
Instead, the system looks for ACL rules on fields and tables.
Warning: After you install the Contextual Security Manager, you

must secure fields and tables via ACL rules. Even if you Configuring
the form layout the dictionary form and add roles to a dictionary
entry, no change in rights occurs.

associated.
Contextual security and roles
You can grant roles to users or groups. However, after installing the
Contextual Security Manager, the roles field on the user record is no
longer checked and no longer appears on your user and group forms.
Instead, you must add roles to the Roles related list instead of to the user
or group record.
Applications and modules contain lists of the roles required to view them.
For example, to view the System Definition application, the admin role
is required. Security rights for applications and modules are still defined
using role arrays.
Both catalog items and catalog variables contain lists of the roles
required to view them. Security rights for catalog items and catalog
variables are still defined via these role arrays.
Under the Contextual Security Manager, a group still automatically

inherits any role granted to the group when the inherits flag for the role is
set to true.
Activating the Contextual Security Manager
The Contextual Security Manager is active in the base system. If there are
many duplicate entries in the User Roles table, you may need to upgrade
to Contextual Security: Role Management V2 to eliminate duplicate
roles. Plugins include:
Contextual Security: Role Management [com.glide.role_management]
Provides contextual security functionality. This plugin is automatically

installed.
Contextual Security: Role Management V2

[com.glide.role_management.inh_count]
Prevents duplicate entries caused by inherited roles in the User Roles

[sys_user_has_role] table. This plugin is automatically installed on new
instances and can be activated for upgrades. The Contextual Security:
Role Management Enhancements plugin is a previous version of this
plugin. The Role Management Enhancements plugin does not include
the RoleManagementVerify() script. This script returns a list of changes
that an upgrade will perform, enabling you to monitor changes made by
the plugin.

associated.
Note: After activating Role Management V2, you must set the
glide.role_management.v2.audit_roles system property to allow the
Audit Roles table to create audit records related to user roles. To
learn more about setting this property and about the Audit Roles
table, see:
• Enable role auditing with Contextual Security: Role Management

V2.
• Contextual Security: Role Management plugin in Instance Security

Hardening Settings.
• Audit user roles
Prevent duplicate entries with Contextual Security: Role

Management V2
Roles inherited from other roles are added as individual entries in the
User Roles table [sys_user_has_role], potentially causing one role to have
duplicate entries. Contextual Security: Role Management V2 eliminates
these duplicate entries and prevents future duplicates.
Eliminate duplicate entries through inheritance count
Contextual Security: Role Management V2 uses the Inheritance Count

(inh_count) column to track the number of times a role is inherited from
another role or group. In the User Roles [sys_user_has_role] table, a user
can inherit a specific role only one time, eliminating duplicate entries. The
Inheritance Count (inh_count) column is read-only and calculates the
number of times the user inherits a role.
Activation changes
Contextual Security: Role Management V2 is automatically installed on

new instances and can be activated for upgrades. When activated,
Contextual Security: Role Management V2 replaces both Contextual
Security and Contextual Security: Role Management Enhancements.
When Contextual Security: Role Management V2 is activated, the

following columns are deprecated, but remain in the User Roles table
for backward compatibility:

associated.
• granted_by (used only by Role Delegation)
• included_in_role
• included_in_role_instance
Warning: If these columns are in use in any custom scripts on your

instance, do not upgrade to Role Management V2.
Visualize role inheritance through the Role Inheritance Map

The Role Inheritance Map displays a visual representation of inherited
roles. You can use this map to understand the roles represented in the
Inheritance Count (inh_count) column. To view the Role Inheritance Map,
configure the User Roles [sys_user_has_role] table to display the Role
Inheritance Map column.
Role Inheritance Map
Upgrade to Contextual Security: Role Management V2

Contextual Security: Role Management V2 is automatically installed
on new instances. You can upgrade from Contextual Security: Role
Management to Contextual Security: Role Management V2 to eliminate
duplicate roles in the User Roles table and prevent future duplicates.
Before you begin
Role required: admin, security_admin
You must have the admin role and Elevate to a privileged role to obtain
the effective security_admin role.

associated.
Note: Before upgrading to Contextual Security: Role: Management

V2, you must enable the Audit Roles table to create audit records
related to user roles. To learn more about setting the required system
property, see Enable role auditing with Contextual Security: Role
Management V2.
About this task
This procedure describes how to upgrade your Contextual Security role

and how to activate the related plugins described in the following table.
Plugins for Contextual Security: Role Management V2
Plugin Description
Prevents duplicate entries in

the User Roles [sys_user_has_role]
Contextual Security: Role
table.
Management V2
The security_admin role or a user
[com.glide.role_management.inh_
with elevated privileges is required
count]
to activate the plugin, or contact
Customer Service and Support.
Contextual Security: Role

Management V2 REST API
Enables API functionality for role
[com.glide.role_management.inh_ management.
count.rest_api]
Before upgrading from Contextual Security: Role Management to

Contextual Security: Role Management V2, test the results of an
upgrade by running the script. The script returns a list of changes that
an upgrade will perform. If the changes are acceptable, install the
Contextual Security: Role Management V2 plugin. If the changes are not
acceptable, do not install the Contextual Security: Role Management V2
plugin. Alternatively, you can perform the upgrade and then manually
make any necessary changes.

associated.
Procedure
1. Test the impact of an upgrade prior to upgrading by running the

following script.
a. Navigate to System Definition > Scripts - Background.
b. Run the following script in global scope.

new RoleManagementVerify().verifyInheritedRoles();
For large sys_user_has_role tables, the execution may take up to
several hours to complete. Do not edit or add user roles during
this time.
Example result based on test data:
*** Script: 2016-12-01 19:58:54 Starting checking o
f inherited roles for all users...
*** Script: User: itam, inherited roles to be ADDED
: financial_mgmt_user
*** Script: User: bernard.laboy, inherited roles t
o be DELETED: api_analytics_read,pa_viewer,rest_api
_explorer,a123
*** Script: User: bernard.laboy, inherited roles t
o be ADDED: dependency_views
*** Script: Number of inherited-role records in sy
s_user_has role, current: 260, after re-calculation
: 258
*** Script: Number of users with discrepancies for
inherited roles: 2
*** Script: 2016-12-01 19:58:55 Finished checking o
f inherited roles for all users!
c. Evaluate the script results to determine whether the proposed

changes are acceptable.
2. Activate the Contextual Security: Role Management V2 plugin.

Important: The security_admin role or a user with elevated
privileges is required to activate the plugin, or contact Customer
Service and Support.
a. Navigate to System Definition > Plugins.
b. Find and click the plugin name.

associated.
c. On the System Plugin form, review the plugin details and then
click the Activate/Upgrade related link.
d. Click Activate.
Result
After activating Role Management V2, the changes outlined in the script
result are enacted. The Inheritance Count (inh_count) column in the User
Roles table is read-only and automatically reflects the number of times
the user inherits a role.
Enable role auditing with Contextual Security: Role

Management V2
Set a system property to enable the Audit Roles table to create audit
records related to user roles.
Before you begin
Role required: admin
About this task
When enabled, the Audit Roles [sys_audit_role] table maintains

changes to user records. For more information about role audits, see
Audit user roles. If the Contextual Security: Role Management V2
[com.glide.role_management.inh_count] plugin is installed, you must set
a system property to true to enable role auditing.
Procedure
1. Navigate to the System Properties [sys_properties] table.
2. Add the glide.role_management.v2.audit_roles system property and

set it to true.
If the Contextual Security: Role Management V2

[com.glide.role_management.inh_count] plugin is installed, setting
this property to true enables the Audit Roles [sys_audit_role] table to
create records when user roles change.

associated.
Double-check form submission

When the system determines that a particular field (such as task.number)
should not be written to by the current user, the system renders that field
in a read-only mode, which is why the number field is not writable on
most incidents.
If you set the system to double-check the values of any incoming fields
for writability, then the system applies the same set of security rules to
the inbound leg of a transaction. When you submit an incident, for
example, the system double-checks to determine if the number field can
be written to before posting any changes.
If you tell the system not to double-check inbound transactions, then the
system allows you to write to a nominally read-only field if that is the
transaction the client sends back. In many deployments this is actually
a desirable behavior if, for example, you are using client scripts to set
nominally read-only fields in response to user selections in other, writable
fields.
Property Location Default
Double check
security on inbound
transactions during System Properties > Disabled (no double-
form submission (rights Security checking)
are always checked
on form generation)
Default deny property

The default deny property (glide.sm.default_mode) controls the
security manager default behavior when the only matching ACL rules
are the wildcard table ACL rules.
A set of wildcard table ACL rules for the most common record-based
operations are available: read, write, create, and delete. A significant
number of ACLs to provide role-based access to system tables are also
available. For example, there are ACLs that grant sys_script access to the
business_rule_admin role because that role is documented as being able
to manage business rules.

associated.
Use the glide.sm.default_mode property to deny or allow these

operations on all tables:
• Deny Access: The wildcard table ACL rules restrict the read, write,
create, and delete operations on all tables unless the user has the
admin role or meets the requirements of another table ACL rule. Other
operations, such as report_on and personalize_choices, are unaffected
by this setting.
• Allow Access: The wildcard table ACL rules allow the read, write,
create, and delete operations on all tables unless there are specific
table ACL rules in place to restrict such operations.
You cannot reset glide.sm.default_mode to Allow Access once it has

been set to Deny Access.
Note: By default, the wildcard table ACL rules are the only ACL rules
that check for the value of the glide.sm.default_mode property.
If you want to control other operations with this setting, create your
own ACL rules to check for this property value.
To learn more about this property, see Default deny in Instance

Security Hardening Settings.
Advanced ACL configuration

In addition to creating new ACLs or modifying existing ones, you can
configure other aspects of ACL functionality.
Task Description
Enable a property to allow script

conditions to apply to reference
fields if you want to control access
Apply ACL script conditions to to the data that a reference field
reference fields displays on a form or in a list.
There might be an impact to the
performance of your instance if
you enable this.

associated.
Task Description
Apply ACLs to GlideAjax API calls

Apply ACLs to AJAXGlideRecord so that the system queries only the
(client-side Glide record) data that the currently connected
user has rights to access.
Force ACL evaluation for admin

overrides at the access level. By
default, users with the admin role
Evaluate the admin override at the
automatically pass the permissions
access level
check for this ACL rule when the
Admin Overrides option is selected
on the ACL rules form.
Use tools like the ACL watcher,

Use ACL debugging and field level debugging, and access
troubleshooting tools ACL rule output messages to help
you troubleshoot and debug ACLs.
Provide external users access to a table

To enable users with only the snc_external role to access the list view of a
table, you must create a series of ACLs.
Before you begin
Procedure
1. Elevate to a privileged role.
2. Create an ACL rule with the following settings:
• Type: ui_page
• Operation: read
• Name: {table_name}_list
• Required role: snc_external

associated.
3. On the default read ACL for the table, add snc_external in the
Required role list.
Create the ACL if it does not already exist.
4. Use these settings to create another ACL:
• Type: ui_page
• Operation: read
• Name: {table_name}
5. Use these settings to create another ACL to give the user write
access to a field in the table:
• Type: record
• Operation: create
• Name: {table_name} {column_name}
Repeat this step for every field that you want to give the user write
access to. Use an asterisk * instead of the column name to provide
access to all fields at once.
Apply ACL script conditions to reference fields

Use the glide.sys_reference_row_check system property to enable
scripted conditions for reference fields.
The default behavior is intended to improve instance performance. If you

want to enable script conditions for reference fields, add the following
system property.
Note: For more information on creating system properties, see Add

a system property.

associated.
System property
Property Description
Controls whether the script

conditions of Access Control Rules
apply to a table's reference fields.
• Type: true | false

glide.sys_reference_row_check
• Default value: false
• Location: Add a system property

to the System Properties
[sys_properties] table
Note: If the glide.sys_reference_row_check system property is

not present, or has been set to false, script conditions for Access
Control Rules are not applied. This means an ACL containing scripted
conditions will pass it's check as long as the other ACL criteria are
met (such as role requirements).
Apply ACLs to AJAXGlideRecord (client-side Glide

record)
Use a system property to perform access control list (ACL) rule validation
when server-side records (for example, tables) are accessed using
GlideAjax APIs within a client script.
If you choose to apply access control lists (ACL) to GlideAjax API calls,
then you can only query data to which the currently connected user has
rights to access. For example, if the user is logged in as an ESS user who
has no rights to read the cmn_location table, then any GlideAjax API
call by the user will fail.
If you run the system without an ACL checking on GlideAjax calls, then
the API can return information that the currently logged in user could not
otherwise access via the UI.
Note: Set this property in System Properties > Security.

associated.
Property Default
Apply standard security ACLs to

ACL checking enforced
AJAXGlideRecord calls
Note:
To learn more about this property, see Enabling AJAXGlideRecord

ACL checking in Instance Security Hardening Settings.
Evaluate the admin override at the access level

If you want to force ACL evaluation for admin overrides at the access
level, you can add a system property.
Before you begin
About this task
ACLs are evaluated cumulatively. If there are number of ACLs on any

given field and the Admin Overrides option is false (not selected) on
one of them, then the effective admin overrides for all the ACLs are
considered to be false. This causes admins to be unable to pass even the
ACL where the override should be in effect.
Procedure
Add the following property to the system properties table:
Evaluates the admin override

condition at the access term level.
glide.security.admin.override.acce
• Type: true | false
ssterm
• Default value: true for new
instances, false for upgrades

associated.
• Location: Add to the System
Properties [sys_properties] table
Note: If the property is not

defined on the Instance, the
value evaluates as false.
ACL debugging tools

Field level debugging and access ACL rule output messages are
available to help you troubleshoot and debug ACLs. The ACL
configuration watcher lets you know what related ACLs exist when you
modify one.
Field level debugging
When debugging is enabled, a small bug icon ( ) appears beside each

field with an ACL rule. Clicking the icon lists the ACL rules that apply for
the field and the evaluation results. Enable debugging by navigating to
System Security > Debugging > Debug Security Rules.
Field level security on an incident

associated.
After enabling ACL debugging, you can impersonate another user to

see what ACL rules the user passes and fails. When you impersonate a
user, you can only see what that user is allowed to see. For example,
you cannot view a record that an ACL prevents the user from seeing. To
make debugging easier, read-only access to certain ACL-related tables
is enabled by default, even when impersonating a user that does not
have read access to the tables. To change this functionality, set the
following property to false.
To enable ACL rule debugging, navigate to System Security > Debug

Security Rules.
System property Description Default setting
true
Note: When
Allows read access to the property is
the following tables set to false,
while impersonating a the impersonated
user: sys_security_acl, user might
sys_security_operation, be prevented
glide.security.access_ sys_security_type, and from reading ACL-
acl_as_impersonator sys_user_role. As related data.
a result, the In this case,
impersonating user a second
can read data that session logged
the impersonated user in as admin
cannot read. or security_admin
might be required
to debug ACLs.
ACL rule output messages
ACL debugging displays ACL rule output messages at the bottom of

each list and form. The output message displays the following:

associated.
Message element Description
The total time used to process this

TIME
ACL rule.
Information that uniquely identifies

each ACL rule in the format:
PATH
<ACL rule type>/<ACL rule name>/
<Operation>.
The object being evaluated by the

CONTEXT
ACL rule.
The return code of the ACL rule. A

RC true value passes the ACL rule. A
false value fails the ACL rule.
A brief summary of processors

and scripts, followed by ACL
results for each table-level and
field-level ACL evaluation. Most
ACL evaluations show an overall
pass or fail result followed by a
breakdown of the results for each
type of ACL criteria:
• iAccessHandler: An internal
system check using hidden
source code on the platform.
RULE
This is a system security
check that you cannot
modify. IAccessHandler can
grant or deny access to a
resource without evaluating
ACLs. If IAccessHandler is
ignored, then the ACLs are
evaluated. You cannot modify
the IAccessHandler checks in
any way. For example, an
IAccessHandler implementation
is used for access checks on

associated.
Message element Description

application resources and this
cannot be changed.
This is available starting with the

Istanbul release.
• Roles: Verification that the user

has the correct role.
• Condition: Verification that the

user passed the condition
specified on the ACL rule (if any).
• Script: Verification that the user

passed the script specified on
the ACL rule (if any).
The icons that appear show how the ACL was evaluated:
Icon Description
Indicates the table or field passed

A green checkmark ( ) the criteria.
Indicates the table or field did not

A red x icon ( ) pass.
Indicates the ACL evaluation did

An empty gray circle icon ( ) not need to be performed.
Indicates that the ACL was taken

A blue checkmark, x, or empty from a cached result of a previous
circle ACL check. The icons mean the
same as the above.
You can perform these actions on the ACL debug output:
• Select or clear these check boxes at the top of the debug output:
• Security rules: Show or hide the results of the ACL checks.

associated.
• Others: Show or hide other warnings or messages.
• Click the name of the ACL next to any of the output messages to open
that ACL record.
• Hover the cursor over any of the icons for the four ACL checks to see
more information.
ACL troubleshooting reference

A list of common ACL rule errors and their solutions.
Enable debugging to help troubleshoot an issue.
Troubleshoot
Error or symptom Solution
Create a table ACL rule for the

custom table granting users access
to the table. Without an explicit
You cannot access records from a table ACL rule, users must pass the
custom table. permissions in the table wildcard
(*) ACL rule, which by default
restricts access to administrators
only. Enable debugging and

associated.

determine what ACL rules are
evaluated for the custom table.
The most likely problems are that

another rule takes precedence
over your custom rule in the
You create a custom ACL rule that processing order or that the user
does not work properly. does not meet all the permission
requirements for the object type.
Enable debugging and verify that
the ACL rule is being evaluated.
There is likely a table ACL rule

that the user has not met. Enable
debugging and determine what
Your field ACL rule does not work
ACL rules are evaluated for the
properly.
field. Verify that there is not
a conflicting table ACL rule or
duplicate field ACL rule.
There is either an ACL rule higher

in the processing order or a
duplicate table ACL rule interfering
Your table ACL rule does not work
with the table ACL rule. Enable
properly.
debugging and determine what
ACL rules are evaluated for the
table.
It is possible that the ACL rule

conditions or script are being
triggered in the list but not in
the form. Enable debugging and
You can see a field in a list but not
determine when the ACL rules
in form.
evaluate to true. Update the
conditions or script to have the
same behavior on the list and
form.
There is an ACL rule for the

You receive an error message
processor or client-callable script
when trying to execute a
include that the user has not met.

associated.

If the user should have access
to the object, enable debugging
and determine what ACL rules
processor or client-callable script
are evaluated for the processor
include.
or script include. Update the ACL
rule or the user roles as needed to
access the object.
ACL configuration watcher

The ACL configuration watcher lets you know what related ACLs exist on
a table when you insert, update, or delete an ACL on the same table.
The ACL configuration watcher is an interceptor window that displays

every time you make important changes on the Access Control
[sys_security_acl] table. It displays a security rules summary window
where you can view ACLs related to the one you are modifying. You
cannot modify any ACLs from the security rules window. To make any
modifications, close the watcher window and go to those ACLs.
The ACL configuration watcher does not appear in the following

situations:
• If you save or update an ACL record without actually making any

changes.
• If you make minor updates (not an insert or delete), such as updating

scripts, conditions, and the admin-overrides option.
• If the ACL record is not active.
ACL Security Rules window
The configuration watcher shows the ACL execution plan. The execution
plan is displayed in the security rules pop-up window. You can view this
kind of information:

associated.
ACL configuration window elements
Item Description
An ACL that is deleted or

red highlight
deactivated.
blue highlight An ACL that is modified.
An ACL that is added or becomes

green highlight
active.
An ACL that was effective until you

Masked
made a change.
An ACL that was just made

Unmasked effective when you made a
change.
Configuration watcher example
Administrators can view how ACLs relate to each other by viewing an

execution plan for any ACL in the instance.
Before you begin

associated.
Procedure
1. Elevate to a privileged role.
2. Navigate to System Security > Access Control (ACL).
3. Open an ACL with the type record.
4. Click Show ACL Execution Plan in the Related Links section.
The security rules window appears for the ACL. The example displays
the execution plan for "vtb_task".

associated.
ACL execution plan window
UI item Description
Title The name of the ACL.
If the ACL is create, read, write,

Tab name
or delete.
Row-level ACLs that run on this

Row level
table.
Field-level ACLs that run only on

Field level
this field (or column in the table).
5. Click Show all to show all related ACLs, including those ACLs that are
overridden and generic ACLs that apply to all records.
Overridden ACLs have a line through the name, and generic ACLs
have the wildcard character asterisk (*) for the name.
6. Show only the immediate ACLs related to the one you are viewing
and hide the ACLs on tables from which the ACL table is extended
and the generic wildcard (*) ACLs by clicking Show Effective.
Use the ACL configuration watcher after you elevate to security_admin

role.
Before you begin
Elevate to a privileged role
Procedure
1. Open an ACL that is a record-type ACL.
2. Perform an action on the ACL, such as modifying it, or selecting an

option from the context menu like Insert.
3. If you modified any values on the Access Control form, right-click the
header and select Save or click Update or Delete.

associated.
The Security Rules window appears. The system did not yet perform
the database action on the ACL, so the changes are not yet saved.
These are examples of security rules on the Visual Task Board

application's Private Task [vtb_task] table. See ACL configuration
watcher for a description of the items on this window.

associated.

associated.
4. Just as with the execution plan, you can click Show all to show all
related ACLs, including those that are overridden and generic ACLs
that apply to all records, or click Show Effective to show only the
immediate ACLs related to the one you are viewing.
5. Hover your mouse over any of the ACLs to see a description.

associated.

Washington DC Platform Security 4-20-2024

Uploaded by

Copyright:

Available Formats

Washington DC Platform Security 4-20-2024

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Washington DC Platform Security 4-20-2024

Uploaded by

Copyright:

Available Formats

Washington DC Platform security

PDF generated on April 20, 2024

Some examples and graphics depicted herein are provided for

PDF generated on April 20, 2024 2

Access Control List Rules

Explore Learn about Configure

Exploring Access Control Lists

• The object and operation being secured

• The permissions required to access the object

PDF generated on April 20, 2024 3

The object is the target to which access needs to be controlled. Each

For example, all these entries specify an object:

Type Name Object secured

record [incident].[--None--] The Incident table.

The Active field in the

The record for the

Each operation describes a valid action the system can take on

For example, all these entries specify an operation:

Type Name Operation Operation secured

PDF generated on April 20, 2024 4

The permissions specify when someone can access the named

• One or more user roles to the Requires role list.

• One or more conditions.

• A script that evaluates to true or false or sets the answer variable to

To gain access to an object and operation, a user must pass all

PDF generated on April 20, 2024 5

Permission type Requirement Description

Only allow users with

Only allow updates

ACL evaluation process

• The condition must evaluate to true.

PDF generated on April 20, 2024 6

ACL evaluate permissions

Whenever a session requests data, the system searches for access

PDF generated on April 20, 2024 7

The effects of being denied access to an object depend on the ACL

Pre and post query ACL checks

Pre-query ACL check

PDF generated on April 20, 2024 8

Post-query ACL check

Operation Results of failing an ACL rule on object

User can’t execute scripts on a

User can’t see the New UI action

A create ACL with a condition

User can’t see the object in forms

User sees a read-only field in

User cannot see the Delete UI

PDF generated on April 20, 2024 9

Operation Results of failing an ACL rule on object

User cannot define relationships

User cannot define relationships

Used to control the fields that

User can’t view or personalize

User can’t update records (rows)

User can’t create a report on the

User can’t view the content of a

User can’t right-click a list field and

ACL matching requirements for objects

Matching ACL Rules

3. Match any table name (). For example, .