Role required: security_admin
ACL stands for Access Control List. It specifies which users and/or processes are allowed to access objects, as well as what operations are allowed on given objects.
In SimpleOne, rules for ACLs check users against a set of requirements before they are allowed to work with the data.
ACL in details
ACL rules specify:
- The object to secure
- The operation to secure
- The permissions to be met.
Objects
ACL restricts access to the object. Each object consists of the type and the name of a table, field, or record.
This table gives examples of objects:
| Type | Table | Column | Object Secured |
|---|---|---|---|
| record | Problem (itsm_problem) | (not set) | The Problem table. |
| record | Incident (itsm_incident) | active | The Active field in the Incident table. |
Operations
In ACL, the term operation refers to a valid action carried out on the specified object. Multiple operations can be carried out on some objects, like records.
This table gives examples of operations:
| Operation | Table | Column | Operation Secured |
|---|---|---|---|
| [Create] | itsm_problem | (not set) | Creating records in the Problem table. Generated ACL record name is [Create].itsm_problem |
| [Write] | itsm_incident | active | Updating the Active field in the Incident table. Generated ACL record name is [Write].itsm_incident.active |
Permissions
The permissions specify the details of the access to the named object and operation. Responsible persons should specify permission with the following information:
- User role or roles in the Role field
- Condition (or several) conditions
- A script returning 'true' or 'false' or setting the answer variable to 'true' or 'false'.
See the Create an ACL Rule article to learn more.
To perform a particular operation over a particular object, a user must pass ALL permissions listed in the access control rule. For example, to access an active record in the Article table, a user must meet the following conditions:
| Permission type | Requirement | Description |
|---|---|---|
| Requires role | Requires role: service_owner | Only users with the service_owner role to read articles. |
| Condition | Owned by is (dynamic) Me | The article is available to the owner of the Content Item this article is related to. An empty condition always returns 'true'. |
The acl.disabled property allows disabling all ACL verifications.
To turn of security checks, please follow the steps below:
- Navigate to System Properties → All Properties.
- Find the acl.disabled property using the list search boxes and open it.
- In the Value field, set true to disable security ACL or false to enable it.
Click Save or Save and Exit.
Setting this property to 'true' may damage your SimpleOne instance, so please use it carefully and do not forget to turn it off after all necessary operations.
How ACL evaluate permissions
When data requested, the system checks if there are ACLs matching the requested object and operation. If a matching rule is found, the system checks the user against all the requirements and then either permits access to the object and operation or denies it. If the user does not meet one of the requirements, the system will restrict access.
The system checks all rules related to the requested object. If the user does not meet all ACL's requirements for the requested object and operation, the system denies access to them.
If the requested object and operation do not have related ACLs, the user gets access to it. However, it is a rare case: a set of default access control rules protecting all record operations are delivered in OOB-configuration.
The access denial has different effects on what the user can see or do depending on the ACL itself. For example, a read ACL denial restricts the user from seeing the object. Depending on the object, the user will not see a field, records from a list, or a UI page.
The table below lists the results of failing an ACL rule for a particular operation and object type.
| Operation | Results of ACL rule failing |
|---|---|
| Create | The New UI actions are not displayed on the pages for the user. Records cannot be inserted into the tables via API protocols as well. If a create ACL has a condition specifying a field value, it is always evaluated as false. In newly created records, fields are regarded as empty until the record is saved. |
| Read | The form and list objects are not displayed for the user. Records cannot be retrieved via API protocols as well. |
| Write | The form fields are not editable for the user: they are read-only. Records cannot be updated via API protocols as well. |
| Delete | The Delete UI actions are not displayed on the forms for the user. Records cannot be deleted from the tables via API protocols as well. |
