Versions Compared

Old Version 46

changes.mady.by.user Anna Kryzhanovskaya

Saved on

compared with

New Version Current

changes.mady.by.user Anna Kryzhanovskaya

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

ACL rules allow securing access to objects and operations depending on your business processes.

Tip

Role required: security_admin.

Elevate your privileges to this role to create or perform any other operations with ACL rules.

To create an ACL rule, please complete the following steps:

  1. Navigate to the System Security → Access Control (ACL).
  2. Click New and fill in the fields.
  3. Click Save or Save and Exit to apply changes.

For example, you can restrict changing states of a task to users who are not involved in the process (editing is available only to the assignee). In the User case section of this article, we examine the following case: you need to hide specific information about employees so that other employees cannot see confidential information and protect information about their roles in the system.

Info

...

ACL check is performed using three fields combined:

  1. Roles
  2. Condition
  3. Script.

If the Roles field of the ACL rule is empty, the next step is the condition check, if any specific condition was put down. If the Condition field is empty, then the Script field is to check for the specific conditions, attributes, or checks.

If any of these steps fail,

...

the ACL check fails, too. That is, ACL does not check the next steps if the previous fails.

The scheme below represents the ACL check process:

Image Modified

Creating an ACL rule

Tip

Role required: security_admin.

Elevate your privileges to this role to create or perform any other operations with ACL rules.

To create an ACL rule, please complete the following steps:

  1. Navigate to the System Security → Access Control (ACL).
  2. Click New and fill in the fields.
  3. Click Save or Save and Exit to apply changes.

Access control fields

FieldMandatoryDescription
NameY

This field is read-only and will be populated automatically by the system after saving the record.

The word in square brackets indicates the operation. The name after the first period indicates the secured table and the column (if there is one specified in the Column field) after another period:

[Delete].sys_history

[Read].sys_history.created_by

Info

This field supports

...

the asterisk (*) wildcard character in place of a record, table, or field name, which allows

...

selecting all objects matching a record type, all tables, or all fields.

A wildcard character and a text search cannot be combined.

Good

problem.*

*.task

Badpro*



OperationY

Select the operation to secure. Available options:

  • create
  • read
  • write
  • delete.
Info

One ACL rule can secure only one operation. To secure over one operation, create a separate ACL rule for each of them.


Any TablesNSelect this checkbox to secure all tables in the system. When selected, the Table field will be hidden until unchecked.
TableY

Specify a table to

...

secure.

Info

One ACL rule can secure only one table. To secure over one table, create a separate ACL rule for each of them.


DescriptionNEnter a description of the object or permissions this ACL rule secures.
RolesN

Specify the role required to pass the ACL check.

...

After the role is specified, users

...

without this role will not pass this check.

You can select several roles.

Info

Roles are chosen out of the Roles (sys_role) dictionary.


ActiveN

...

Select this checkbox

...

to activate the ACL rule

...

.
Admin OverridesN

Select this checkbox

...

to allow system administrators (users with the admin role)

...

pass the ACL rule automatically. Admin users will access the object or operation regardless of the existing restrictions.

Clear this checkbox to

...

check these users against the rule. Define filters in the condition builder or in the Script field

...

to create a permissions check that admin users

...

should meet to get access.

Any FieldsN

...

Select this checkbox

...

to secure all columns in the system. When checked, the Column field will be hidden until unchecked.
ColumnN

Select a column to

...

secure.

Info

One ACL rule can secure only one column. If you want to secure over one column, create a separate ACL rule for each of them.


ConditionN

Define permissions to

...

meet in the 

...

Condition Builder.

ScriptN

Specify a script implementing the permissions to

...

meet. The script

...

execution result is the answer variable equal to 'true' or 'false'.

Image Modified

User case 
Anchor
ACL user case
ACL user case

Panel
borderStylesolid

Case 1:

The company asks to hide the following information about employees:

    • Mobile Phone
    • User Role.

Access to this information should be available to users with the user_manager and admin roles and the employee themselves (an employee cannot see the mobile phone and roles of other employees).

To complete the task we set up two ACL rules:

Section
bordertrue


Column

ACL №1 allows access to the Mobile Phone field for the record owner:

FieldValue
Operationread
Admin Overridestrue
TableEmployee
ColumnMobile Phone
Condition

ID is javascript: return ss.getUserID();


An ACL rule is created: [Read].employee.mobile_phone


Column

ACL №2 allows access to the Mobile Phone field for user managers:

FieldValue
Operationread
Admin Overridestrue
TableEmployee
ColumnMobile Phone
Rolesuser_manager

   .

An ACL rule is created: [Read].employee.mobile_phone


The result is the following:

Section
bordertrue

These two screenshots illustrate the Employee list with ACLs №1 and №2.


Column

The list of records shown to the owner of the employee record without the user_manager role (Stepan Petrov):

Image Added


Column

The list of records shown to a user with the user_manager role:

Image Added



Panel

Case 2:

We need to allow access only to one field in the Request (itsm_request) table, but creating ACLs for every field we need to protect is not effective.

For these purposes we create two ACLs:

    • [Write].itsm_request.additional_comments – allows access to editing the Additional Comments field.
    • [Write].itsm_request.* – restricts access to all fields to users without the ITSM agent role. The restriction works for every field for which there are no allowing ACL rules.

Let us examine the differences between them.


Section
bordertrue

Since this ACL rule does not specify roles and conditions, it is the allowing ACL rule.

Column

[Write].itsm_request.additional_comments

FieldValue
Operationwrite
Admin Overridestrue
TableRequest
Any Fieldsfalse
ColumnAdditional Comments



Column

[Write].itsm_request.*

FieldValue
Operationwrite
Admin Overridestrue
TableRequest
Any Fieldstrue
RolesITSM_agent




Section

These ACL rules ensure that the caller (or any other user who is not an agent) cannot edit record fields. Only users with ITSM_agent and admin roles can do that. At the same time, the caller can leave comments to communicate with the assigned user or group.

In other words, the ACL rule marked with the asterisk (*) wildcardcharacter works on every field except those which have their own ACL rules.


Table of Contents
absoluteUrltrue
classfixedPosition
printablefalse