Users
Users are created automatically on their first login. Users can also be created manually and the desired roles can be assigned before the users login for the first time.
User is locked: Enabling this setting will disable the user from logging in.
Inherit roles from Active Directory: This setting is only visible when Windows authentication is used. It overrides the role assignment and uses Active Directory security groups for the user.
Roles: The roles assigned to the user.
A user may be assigned to multiple roles. If the user is not assigned to any role and "Inherit" is not enabled, the user will not have any permissions.
Note that if a user is assigned to multiple roles, the rules from those roles will be combined, and any deny rules will take precedence over Allow rules. For example, if the user is part of an "Administrators" role with access to everything, as well as a "Users" role with access to all Views except the User Management View, then the user will not have access to the User Management Page, even if they are in the "Administrators" role.
Roles
A role has a collection of rules that are used to restrict or allow users to access Views, Processes, or Environments.
There are multiple different types of rules:
AllowAction: a rule that describes the activities that the user in the role can do.
DenyAction: a rule that describes the activities that the user in the role explicitly cannot do.
AllowTag: a rule that allows the users in the role to only see Processes with the Tags.
DenyTag: a rule that explicitly hides the processes with the Tags.
AllowEnvironment: a rule that allows the users in the role to only see the Environment given.
DenyEnvironment: a rule that explicitly hides the Environment given for the users in the role.
Multiple Roles
There can be multiple roles, and each role can have multiple allow or deny rules. There is no hierarchy between the roles. If a user belongs to multiple roles that have different rules defined, the rules from each role are combined as if they would come from one Role. This can have unintended consequences, therefore it is usually recommended to use only one Role per User. For example, if the User has multiple Roles all rules are combined essentially with AND keyword, not with OR. Therefore if you combine rules allow Tag Finances from one Role and allow Tag HR from another. Frends will show only processes with both tags. Not any process with only HR or Finances tag or with both tags.
Limit access to Views and actions - Activity
The activity-based configuration is based on a two-part configuration scheme where individual activities are defined by the controller and action names. A Controller essentially represents a menu item on the UI, and an action is functionality available for the user to perform. The following activities are available for configuration:
*.*All permissions*.AdminAdmin permissions*.EditEdit permissions*.ViewView permissionsApiManagement.*APIs All permissionsApiManagement.ViewAPIs View permissionsApiManagement.EditAPIs Edit permissionsProcess.*Process All permissionsProcess.ViewProcess View permissionsProcess.EditProcess Edit permissionsProcess.DeployProcess DeployProcess.StartProcess Run onceProcessinstance.*Process instance All permissionsProcessinstance.ViewProcess instance View permissionsProcessinstance.EditProcess instance Edit (terminating and deleting instances, acknowledging errors) permissionsEnvironment.*Environment All permissionsEnvironment.EditEnvironment Edit permissionsEnvironment.AdminEnvironment Admin permissionsTask.*Task All permissionsTask.ViewTask View permissionsTask.EditTask Edit permissionsMonitoringRules.*Monitoring rules All permissionsMonitoringRules.ViewMonitoring rules View permissionsMonitoringRules.EditMonitoring rules Edit permissionsEnvironmentVariables.EditEnvironment variables Edit permissionsUserManagement.AdminUser management Admin permissionsApiKeyManagement.AdminAPI Keys Admin permissionsCommon.ViewCommon View permissions
The following wildcards are supported for activities:
*.*Match all activities*.{action}Match all actions with given name in every controller{controller}.*Match all actions for the given controller
The order of the activities being authorized is as follows:
Explicitly allowed activity (e.g., Process.Start)
Explicitly denied activity (e.g., Process.Deploy)
Wildcard allowed activity (e.g., Process.*)
Wildcard denied activity (e.g., *.Edit)
Full allow wildcards (*.*)
Full deny wildcards (*.*)
This means that if an activity has been configured with an explicit allow option, then it cannot be overridden by any following value.
When creating a new role, you should always add the "Common.View" rule, as it is required, for example, for seeing the navigation menu, as well as other common Views.
Example
A operator that can view everything and edit Process executions (Process Instances). The users of this role can acknowledge errors and start new Process executions.
Default roles
Users: Legacy role from older Frends. This allows access to everything except user management.
Editor: Allows every Edit Action.
Administrator: Allows every Action
Viewer: Allows every View Action
Limiting access to only specific Processes - Tag
You can limit the Processes a role can see and access by using Tags and the AllowTag and DenyTag rules. The rules work the same way as the View rules (allow and deny). However, the view rules take precedence: if you cannot, for instance, edit Processes, you cannot edit them even if the Tag would allow you to.
If no Tag rules are active for a user, the user can see all processes.
Wildcards are not supported.
The AllowTag rule limits the users in the role to seeing and accessing only the Processes with the defined Tag.
The DenyTag rule allows the users in the role to access and view all Processes except those that are denied.
You cannot use both Allow- and DenyTag rules at the same time as they would conflict.
Limiting access to only specific Environments - Environment
You can limit the Environments that users in a role can see and access using the AllowEnvironment or DenyEnvironment rules.
If no environment rules are active, the user can see all Environments.
Wildcards are not supported.
The AllowEnvironment rule limits the users in the role to only see and access the Environments with the defined Environment
The DenyEnvironment rule allows the user in the role to see and access all Environments except those that are denied.
Example
The role allows users to perform all actions except for administrative actions and accessing the Environments: Default, Test, and Staging.
Note: Everyone can always see the "Default" environment and, the AllowEnvironment and DenyEnvironment rules cannot be used simultaneously for the same role, as they would conflict.
The next article is Example on Access Management Configuration