Permissions
WHO CAN DO WHAT
Permissions bind users to resources.
Overview
Each resource has an inherent set of roles it supports. For some, its a single role (e.g. SSH, you either can, or cannot, use). Others can be more fine grained (e.g. a Share can be Read-Only (Viewer) vs Read-Write (Editor). For Web Applications, these roles are user defined (e.g. Managing-Editor, Contributor in a web site).
A permission is the assigning of which user (or group) has which role in which resource.
Permissions are assigned under Access/Application Permissions (for web applications), and, Access/Resource Permissions (for all other resources such as a Share, Desktop, Launcher, etc.)
Application Permissions
To assign users (or groups) permissions to a web application, enter the ID (user email or group ID) on a new row, and then set the permission on each column.
Agilicus recommends using Groups (so assign users to the group, assign permissions to the group) as it reduces configuration requirements.
Resource Permissions
For resource permissions, enter a new user or group row, and then add each individual resource permission as a ‘chip’. Start by typing the resource name, and then select the role. The roles are often Owner (all permission) or Self (all permission).
Diagnose User Permission Issues
To determine how an individual user might interact, you can use the Access/Audits menu. Enter a few letters of the user email and search. Below you will see the entire set of permissions, and, recently used access.
