Role-Based Access Control
Details on how to fine tune access to your Frends Tenant.
Frends uses a flexible and granular Role-Based Access Control (RBAC) system to manage user permissions. You can access the settings through Administration > User Management view.
Available Rules
The following rule types, or permission types, are available for setting for each role.
AllowAction
This rule describes the activities that the user in the role can do.
DenyAction
This rule describes the activities that the user in the role explicitly cannot do.
AllowTag
This rule allows the users in the role to only see Processes with a specific Tag.
DenyTag
This rule explicitly hides the Processes with specified Tags.
AllowEnvironment
This rule allows the users in the role to only see the Environment given.
DenyEnvironment
This rule explicitly hides the Environment given for the users in the role.
Available Activities
The following activities are available for using with AllowAction and DenyAction rules, to allow or limit access to features in Frends Control Panel. Provided auto-complete feature will also guide you in what is available to use while editing a role.
*.*
All permissions
*.Admin
Admin permissions
*.Edit
Edit permissions
*.View
View permissions
ApiManagement.*
APIs - All permissions
ApiManagement.View
APIs - View permissions
ApiManagement.Edit
APIs - Edit permissions
ApiMonitoring.*
API Monitoring - All permissions
ApiMonitoring.View
API Monitoring - View permissions
ApiMonitoring.Edit
API Monitoring - Edit permissions
ApiPolicy.*
API Policies - All permissions
ApiPolicy.View
API Policies - View permissions
ApiPolicy.Edit
API Policies - Edit permissions
Process.*
Process - All permissions
Process.View
Process - View permissions
Process.Edit
Process - Edit permissions
Process.Deploy
Process - Deploy
Process.Start
Process - Run once
Process.Admin
Process - Admin permissions
Processinstance.*
Process Instance - All permissions
Processinstance.View
Process Instance - View permissions
Processinstance.Edit
Process Instance - Edit (terminating and deleting instances, acknowledging errors)
Environment.*
Environment - All permissions
Environment.Edit
Environment - Edit permissions
Environment.Admin
Environment - Admin permissions
Task.*
Task - All permissions
Task.View
Task - View permissions
Task.Edit
Task - Edit permissions
MonitoringRules.*
Monitoring rules - All permissions
MonitoringRules.View
Monitoring rules - View permissions
MonitoringRules.Edit
Monitoring rules - Edit permissions
EnvironmentVariables.Edit
Environment Variables - Edit permissions
UserManagement.Admin
User management - Admin permissions
ApiKeyManagement.Admin
API Keys - Admin permissions
ProcessTemplate.*
Templates - All permissions
ProcessTemplate.View
Templates - View permissions
ProcessTemplate.Edit
Templates - Edit permissions
PrivateApplication.*
Private Applications - All permissions
PrivateApplication.View
Private Applications - View permissions
PrivateApplication.Edit
Private Applications - Edit permissions
PrivateApplication.ViewToken
Private Applications - View token(s)
Common.View
Common View permissions (Required for all users)
Activity Wildcards
The following wildcards are supported for activities:
*.*
Match all activities
*.{action}
Match all actions with the given name in every controller
{controller}.*
Match all actions for the given controller
Using Tags for Access Control
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 actions (allow and deny). For example, if you cannot edit Processes, you cannot edit them even if the Tag would allow you to, as it only allows you to view those Processes, not edit.
If no Tag rules are active for a user, the user can see all Processes.
Wildcards are not supported.
AllowTag rule limits the users in the role to just see and access Processes with the defined Tag.
DenyTags allows the users in the role to access and view all Processes except those that are denied.
You cannot use both the AllowTag and the DenyTag rules at the same time, as they would conflict.
Environment Rules
You can limit the Environments 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.
AllowEnvironment rule limits the users in the role to just see and access the Environments with the defined Environment
DenyEnvironment rule allows the user in the role to see and access all Environments except those that are denied.
Combining Roles & Rules
Each user can have multiple roles given to them.
Roles given to a user do not have hierarchy between them. This means that the rules included in each role will be combined.
When combining different rules, explicitly allowing specific content using Allow rule will override any rule that denies it. Explicitly targeted rules to named content will also override any rules using wildcards.
Order of the content being authorized:
Explicitly allowed content (e.g. Process.Start, View specific Tag or Environment)
Explicitly denied content (e.g. Process.Deploy, View specific Tag or Environment)
Wildcard allowed activity (e.g. Process.*)
Wildcard denied activity (e.g. *.Edit)
Full allow wildcards (*.*)
Full deny wildcards (*.*)
Default Roles
Frends comes with several built-in roles, each with a set of permissions.
Administrator
Allows every action, including user management and all administrative tasks.
Default rules for this role:
AllowAction
*.*
AllowAction
UserManagement.Admin
Editor
Allows all edit actions for Processes, APIs and Environment Variables as well as deploying Processes, but access to User Management or editing Environments or Agent Groups.
Default rules for this role:
AllowAction
*.*
AllowAction
Common.View
DenyAction
*.Admin
Viewer
Allows viewing Processes and Environments, but no possibility to edit them.
Default rules for this role:
AllowAction
*.View
AllowAction
Common.View
DenyAction
EnvironmentVariables.View
Last updated
Was this helpful?