ACL Manual - How to Use the Access Control List

Introduction

An Access Control List (ACL) is a security function used to control access to the resources of a system.

This manual provides instructions on how to use and manage the Access Control List (ACL) in Virtus Flow.

Prerequisites

In the standard system configuration, the ACL is accessible to administrators, but not to internal and external users.

To check if your user is allowed to edit the ACL, simply go to the Setup icon (Gear at the bottom of the side menu) and check that the "ACL Management" panel is present; if this is not present, or access to the setup area is not allowed, the user is unauthorized to manage the ACL. In this case, please contact Virtus Flow technical support to enable this configuration.

ACL logic

In Virtus Flow, ACL rules have four basic characteristics: Access Rules, Authorized Users, Nodes on which the rule is applied and Priority.

Access Rules

• Read and Write (RW): allows reading and editing of all nodes assigned to it.
• Read (R): allows you to read the data of associated nodes.
• Access Denied: This is an explicit denial of access to one or more nodes, and is used to ensure the user does not have access to certain nodes.

Assignment

As far as single resources are concerned, rules can be assigned to:

• Resources within the registry.
• Creator resources of the record whose node is the subject of the rule.
• Resources that made the last changes to a record of the node subject to the rule. 

As far as user groups are concerned, assignments can be made on the basis of:

• Role in the system: Administrators, Users, External Users, Anonymous.
• Team membership (e.g. users belonging to the same business area, location, etc.).
• Belonging to the same group as the user creating the record whose node is the subject of the rule.
• For the ticket node only: membership of the team associated with the ticket topic.

Nodes

The ACL may allow access to any node within the system with different levels of detail, from access to the entire node down to individual records; for example, a user may be allowed to view the entire 'Documents' node or be given access to a specific document.

In the example just described, the user will be able to open the document and view its contents, but within the sections, some fields such as: "Document Type", "Document Category", "Attachments" etc... may not be visible (populated with "****"). This is because it is necessary to give the user access to the other nodes that make up the document description.

Priorities

From the characteristics outlined, it can be understood how the definition of different rules within a system can lead to conflicts. In order to define which rule prevails over the others, a priority scale is used which coincides with the ascending order of the list, i.e. the rules that are higher up in the list (with a higher position) prevail over those further down the list in the event of conflicts. An example of rule priority management can be found under 'd' in the section 'Use Cases'.

Configuring the ACL

The steps for creating, editing and deleting ACL rules will be defined below.

Creating a new rule

1. Log in with an ACL-enabled user to Virtus Flow.
2. Enter the set-up menu (gear icon at the bottom of the left-hand side menu).
3. Select the 'ACL Management' panel.
4. To create a new ACL, press the 'Add ACL' button.
5. Enter a 'Description' and mark the status 'Active'.
6. Go to the 'Authorized Users' section and set the rules and users as explained in the previous section.
7. Access the 'Apply to' section
8. Press the 'Add New' button
9. Set 'Node Type', 'Node' (if you want to select one or more specific nodes) and 'Cascading Rules' (if you need to give access to other node types related to the one already entered).
10. Press the 'Add' button
11. Repeat steps 8,9,10 for all node types you wish to give access to.
12. Press on the save button (blue button at top right with floppy disk icon).

Modifying an Existing Rule

1. Perform steps 1, 2 and 3 in the list above.
2. Click on the description of the rule you want to change.
3. Navigate within the rule as explained in the list above and change the desired settings. In the 'Apply To' section next to each rule, there is a button for editing the rule (pencil icon) and one for deleting it (trash can icon).
4. Always press the save button (blue button with floppy disk icon in the top right-hand corner of the modal).

Deleting a rule

1. Carry out steps 1 and 2 in the previous paragraph.
2. Press on the delete button of the rule (red button with recycle bin icon in the top right corner of the modal)

Changing Priority

1. Access the 'ACL Management' panel from the setup menu.
2. Drag and drop on the rule to be moved.

Tester Mode

Within the ACL setting menu there is a window that allows you to test the rules set; the accessibility test can be done for each user on each node.

Tester mode is accessible at the top of the ACL configuration page, as shown in the figure below.

The Tester consists of 3 elements that must be set up sequentially:

• Node Type: allows you to select the type of node on which you want to perform the test.
• Node: allows you to select the specific node to be tested (a ticket, a document, a workflow ...).
• Resource: is the resource subject to the test.

An example of the tester's result can be seen in the following image:

The result shows, for the selected node and user, the access rule set; in addition, a hyperlink is given to the rule responsible for the behavior described by the tester.

The figure shows the test carried out to ascertain the behavior of the ACL defined in example 'b' at the end of the document. It can be seen that the user is enabled to edit and view the "HR" folder; this result does not ensure access to Workflows related to the folder, to verify this, it will be necessary to test the Workflow type node and select a node belonging to the HR folder.

A point of attention must be the user in use at the time of the test, because the list of selectable nodes is influenced by access rules; therefore, if the user does not have access to Workflows, they will not be visible in the tester.

Best Practice

When managing the ACL in Virtus Flow if possible, it is useful to follow the following guidelines:

• Sort the ACL correctly, because Virtus Flow will process it in order; therefore, the more specific rules should be listed first.
• Keep the rule base as simple as possible, as a more complex rule base will have an impact on performance.
• Know in advance the mandatory fields of the node type covered by the rule (as can be seen from example 'a' in the next chapter).
• Given the structure of the ACL in Virtus Flow, when creating a new rule it is important to also give access to the "Administrator" and "Users" roles if all resources with that role are to have access to the node on which the rule is being applied. This must be done because Administrators and Users within the system have privileges on certain nodes not listed in the ACL, and creating a rule on such nodes leads to a removal of these privileges, as illustrated in example 'b'.

Use Cases

In the following chapter, some real-life examples of ACL use will be given; accompanied by descriptions, points of attention and tips.

1. Creation and display of tickets for individual external users:

System configuration that allows a specific external user to create and view tickets related only to the company to which they belong.

Specifically, the ACL below allows the external user "TEST EXT USER" who is a member of the company "TEST EXT COMPANY" to create and display tickets relating to his company. The node type "Company" has also been cascaded with "Ticket", which serves to display existing tickets; note also that "Ticket" has "Communication" and "Notes" linked to it by default; therefore, these two sections will also be visible to the user within the ticket.

In the ACL there are also the node types 'Typologies' and 'Arguments', these are necessary because when creating a new ticket the two node fields just mentioned are mandatory (as can be seen in the following image), so without these the creation of a new ticket will not be successful.

From this example, it can be seen that prior knowledge of the fields required for the correct creation and display of a given node type is crucial for creating effective rules.

1. Creating, editing and visualising workflows for the User role:

System configuration that allows all resources with a 'User' licence to create, edit and view the progress of the HR folder and all processes related to it.

The rule below allows all users to manage and access the "HR" folder and the processes within it. In particular, the assignment of the cascading node "Workflows" allows users to view and edit processes within the Virtus Flow Builder; while the nodes "Workflow Results" and "Macro Workflow Results" allow users to view, on their home page or in the "Progress" menu, the progress of processes within the HR folder.

Administrators have been included in the assignment, this is because by default access to Workflows is not regulated with an ACL, but is a system setting, therefore, application of the rule below, without the addition of administrators, would have resulted in administrators being excluded from accessing and viewing the 'HR' folder and related processes.

1. Data Object visualization for a specific team:

System configuration allowing a specific team to access Data Objects of the indicated type.

The rule shown in the picture authorizes (read-only) access to Data Objects of the 'IT Asset' type to resources belonging to the 'Board Member' team; at the same time, the rule denies access to all Administrators and all Users to Data Objects of the specified type.

With the use of this rule, no resource will be able to modify the 'IT Asset' Data Objects and only members of the team mentioned in the rule will be able to view these Data Objects and their custom fields. Of course, this access restriction will not only affect the customized Data Object tables, but also the other parts of the application that involve these elements; for example, if Data Objects of the type in question were used within a process, the rule below would not allow resources (except those belonging to the team) to view the status of the Data Object and its name within the Workflows progress menu.

1. Priority management of rules:

Configuration allowing the display of Data Objects related to the date type, but denying access to the custom fields of the latter.

There are two rules used, and they present a conflict; in fact, the one in the second position grants selected team members access to the customized fields of the 'IT Asset' Data Objects, whereas the rule in the first position denies team members access to all customized fields.

As mentioned in the section on Priority, with the use of these rules, 'Board members' will be able to view 'IT Asset' Data Objects; however, they will not be able to view any customized field, whether it is a customized field used in a Data Object or used anywhere else in the application.

i A modal window is a 'child' window that requires the user to interact with it before returning to work with the 'mother' window, preventing the continuation of the workflow on the main window of the running application. Modal windows are often called 'heavy windows' or modal dialogues because the window is often a dialogue box.