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
execute	Enables users to execute client callable script includes and REST endpoint execution.
query_match	Enables users to submit match queries("is", "is not", "is empty", etc).
conditional_table_query_range	Enables users to give partial ACL-access based on read ACLs. Created for the tables that have the read ACLs without Data condition and script.
query_range	Enables users to submit range queries("starts with", "ends with", "contains", etc) and sorting is unrestricted.
create	Enables users to insert new records (rows) into a table.
read	Enables users to display records from a table.
write	Enables users to update records in a table.
delete	Enables users to remove records from a table or drop a table.
edit_task_relations	Enables users to extend the Task [task] table.
edit_ci_relations	Enables users to extend the Configuration Item [cmdb_ci] table.
save_as_template	Enables users to save a record as a template.
add_to_list	Prevents users from viewing or personalizing specific columns in the list mechanic. Note: Conditions and scripts are not supported.
list_edit	Enables users to update records (rows) from a list.
report_on	Enables users to report on tables.
report_view	Enables users to report on field ACLs.
personalize_choices	Enables users to configure the table or field.
data_fabric	Allows a data fabric table to reference a local table.

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

Figure 1. 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.

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.

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:

Operation	Description
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.