ACL rule types

You can 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
create Allows users to insert new records (rows) into a table.
read Allows users to display records from a table.
write Allows users to update records in a table.
delete Allows users to remove records from a table or drop a table.
edit_task_relations Allows users to extend the Task table.
edit_ci_relations Allows users to extend the Configuration Item [cmdb_ci] table.
save_as_template Allows users to save a record as a template.
add_to_list Allows users to insert records (rows) into a table from a list.
Note: Conditions and scripts are not supported.
list_edit Allows users to update records (rows) from a list.
report_on Allows users to create reports on tables. This operation is not valid for field ACL rules.
personalize_choices Allows users to configure the table or field.
Record ACL rules are processed in the following order:
  • Match the object against field ACL rules.
  • Match the object against table ACL rules.

This processing order ensures that users gain access to more specific objects before gaining access to less specific ones. A user must pass both field and table ACL rules in order to access a record object.

  • If a user fails a field ACL rule but passes a table ACL rule, the user is denied access to the field described by the field ACL rule.
  • If a user fails a table ACL rule, the user is denied access to all fields in the table even if the user previously passed a field ACL rule.
Figure 1. ACL matching

Processor ACL rules

Processor ACL rules specify the processor you want to secure. Use the asterisk character as a wildcard to search for any processor. 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.

Field ACL rules

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 (wildcard) and field name. For example, *.number.
  4. Match the table and any field (wildcard). For example, incident.*.
  5. Match the parent table and any field (wildcard). For example, task.*.
  6. Match any table (wildcard) and any field (wildcard). For example, *.*.

The first successful evaluation stops ACL rule processing at the field level. This means that when a user passes a field ACL rule, the system stops searching for matching field ACL rules. The user must also pass the table ACL rules to be granted access to the record object. For example, if a user passes the field ACL rule for incident.number, the system stops searching for rules that secure the Number field. The user must then pass the table ACL rules on incident to see the Number field.

Table ACL rules

In most cases there is not an individual field ACL rule for every field in the table the users is trying to access.

If no field ACL rule matches the record object, the user must pass the table ACL rule. Since the base system includes wildcard 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 (wildcard). For example, *.

Just like with field ACL rules, the system grants the user access to the record object secured by the ACL rule and stops searching for matching ACL rules the first time a user passes a table ACL rule's permissions. A user who passes the table ACL rule for incident has access to all fields in the Incident table. A user who passes the table ACL rule for task has access to all fields in the Task table as well as the fields in extended tables. A user who passes the table ACL rule for any table has access to all fields in all tables.

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 wildcard * character in the Name field on ui_page type ACLs to match any UI pages. Prior to Geneva, the wildcard character was not supported for UI page ACLs.

ACL rules can secure the following UI page operations:

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. Use the asterisk character as a wildcard to search for any client-callable script include. 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.