Access rules

In order for users to be able to see and execute a scan workflow on a terminal, you must configure their access. By default nobody has access.

Types of access rules

Access to each individual workflow can be configured via rules on a group or user basis:

• Allow – the given user/group has access to the workflow.
• Deny – the given user/group is denied access to the workflow.

Configuring access rules

1. In the PMC Web UI, go to Scan Workflows > Access.
   

   

   
   

2. To create a new access rule, click Add.
   

   

   You must have both the ViewScanWorkflow and ViewScanWorkflowAccessRule permissions to access the section, and at least CreateScanWorkflowAccessRule permission to create an access rule.

3. Configure the access rule:
   

   

   
   
   • Authentication provider – choose the provider which contains the target users or groups.
   • Workflow – scan workflow for which the access should be granted/denied.
   • Access – choose the type of rule to create for the target users or groups.
   • User or group name – full-text search under the given authentication provider. If you leave the search field blank, all users and groups from the selected provider will be listed.
     In the selection box, either one or multiple users & groups can be selected via standard selection methods (mouse drag, shift+click, ctrl + click).
4. Click Save. If you selected multiple users or groups, multiple access rules will be created after clicking Save.

Effective workflow access evaluation

To determine whether a user has access to a workflow (and therefore can see it on the terminal and execute it), the system is evaluating a combination of all configured rules that apply to the given workflow and target the actual user + any group, that the user is a member of.

Rules are evaluated with the following priority:

• Rules that target the user explicitly have higher priority than rules that target a group containing this user
• Rules that deny access have higher priority than rules that allow access on the same level. For example, deny rule for a group is stronger than allow rule for a group, but it can be overruled by a user-explicit allow rule.

Availability of the workflow for a user is also affected by the "active status" of the workflow itself – even if a user has access to it, inactive workflows aren't shown on the terminal.