Demystifying Access Controls | ACL Basics
Overview
Access controls (ACLs) can seem very intimidating when you are trying to configure your instance security rules. This article is intended to help understanding and eventually mastering the ACLs usage.
Understanding how Access Controls work
The main aspect of the access controls setting is that it is a two-gate system. A logged in user that wants to access a record for a particular operation (read, write, delete) is first evaluated for the particular field(s) they affect in that table, and then checked for the table-level access. One way to think about it would be like when travelling by plane. You first have to get past the common security line for all passengers. This won't get you on your plane, but will allow you to enter the terminal. You then need to pass a second gate to board your actual plane, for which you must have a boarding pass. Access controls work the same way, with the exception that we do not make you remove your shoes at the first gate-check, which gives us a huge advantage over the TSA.
Gate 1 - Field-level access
When a user attempts to access a record from a table, we first check for field level access on the table the user is trying to access (first gate). We start by looking for an ACL for the particular table/field combination for the field on the form. Let's take the incident table for example, and evaluate access to the Caller field (caller_id column). The Name label has two drop-down fields on ACL records. The first field is for the table and the second field is for the actual field. The system searches for an access control whose name is "incident.caller_id" (incident for the first field and caller_id for the second field of the ACL). If it finds one, it evaluates all three pieces of the security check (condition, script, roles). The following example shows a sample for the Caller field (caller_id).
If an ACL is not found for the specific table/field combination, the system looks for a generic field ACL for that table, where the second ACL name field is set to *. In the incident example, that would be an ACL whose name is incident.*, as shown in the following example.
If it does not find that, then it looks for a generic field ACL that applies to all tables, which would have the name *.*, as shown in the following example.
The key for field access is that the process works from the very specific to the generic. The search order is as follows:
- table.field ACL (incident.short_description)
- Parent table.field ACL (task.short_description)
- table.* ACL (incident.*)
- Parent table.* ACL (task.*)
- Generic field ACL (*.*)
Gate 2 - Table-level access
Once all the fields have been evaluated for the particular table being accessed, we move on to the second gate for table-level access. The system checks for an ACL whose name matches the table the user is trying to access. For example, for incidents, the system checks security at the second gate by looking for an ACL whose name is "incident", operation is "read" and type is "record".
The Name label has two drop-down fields on ACL records. The first field is for the table and the second field is for the actual field. So when you want to check for a table-level ACL, you are looking for ACLs where the second field is set to "--None--". The following example shows an incident read table-level ACL:
Once the system finds an ACL, the user must pass ALL THREE pieces of security on that ACL record. First, the user has to have one of the roles defined on the roles related list of the ACL. Next, the system evaluates whether a condition is defined in the condition filter and evaluates that condition if present. Finally, the script is evaluated if it is defined. The script must return true for the user or else access is not granted. If no script is defined, that step is skipped.
If no table-specific ACL is found for the table in question (incident in the example), the system looks for an ACL where the table name matches a parent table in that table's hierarchy (for example, task is a parent to incident). If no parent table ACL is defined, it looks for a * rule (applies to all tables when a table-level ACL is not defined). The following example shows that type of ACL.
In conclusion, to help keep things clear when you work with ACLs, just remember that you are dealing with two gates. Make sure to set up field access (create new ACLs or revise existing ones) for your field-level access (first gate) and that there is a table-level access rule in place for the user(s) in question (second gate). Keep in mind there are security settings that can change the way access controls work, such as High Security.
There is one point that should be clarified with this two-gate system with respect to the Admin Overrides checkbox. If Admin Overrides is selected and the user has the admin role, the ACL will always evaluate to true regardless of the script/condition/role requirements. However, issues can occur if one or more ACLs that are being evaluated at the same time do not have admin overrides checked: all the ACLs that are being evaluated will then ignore admin overrides. So, if you are going to use the Admin Overrides feature, be sure that all the ACLs on the table/fields for that particular operation (read, write, delete, etc.) have the Admin Overrides checkbox checked.
For more information on access controls, see the product documentation topic Access control rules.