Aptli

Authorization

Authorization defines what a user can or can't do after they get access to your application. (./authentication)

Aptli's authorization model combines both permissive and restrictive elements for tremendous flexibility:

  1. Admin Rights — an à-la-carte array granted directly on each user (screenshot pending) and
  2. A restrictive model of Roles applied to users through their role membership (screenshot pending)

Admin Rights

Admin rights are permissive. They are stored as a per-user array (user.admin) — each entry is one right name, granted directly on the user, never inherited from a role. This means permission must be granted to users but only to modify information or alter status. For example, having usersUpdate allows one user to alter some profile details of another user. This would include Name, Title, Division, etc. while excluding changes to email, passwords, SSO, and validation dates. Without this, users can only edit their own profile.

usersLogout is required to hard lock or log out a user and usersDelete is required to delete a user's account. usersCreate can undelete an account or create a unique new one with the field restrictions above.

Work order rights use the workOrders prefix: workOrdersCreate, workOrdersUpdate, workOrdersDelete. (Note: orders is a separate data model — do not confuse the two.)

Nearly all data models behave in this manner and only 3 Admin Rights supercede them all:

  • appSettingSchemasModify which allow modification to application-level settings like allowed domains, timeouts, and server information
  • adminRightsModify which allows users to share and extend admin rights to other users.
  • viewDeleted which allows users to view deleted records. This is nearly universal, though can be partially overridden by Role Restrictios.

Role Restrictions

Roles are Restrictive. This means a role applied to a user prevents that user from viewing and altering records with certain characteristics. A role holds only a name and a collection of Role Restrictions — it carries no members, no owner, and no admin rights. Membership lives on the user: each user has a roles list, and assigning a role means adding it to the user. Creating, editing, and deleting roles is gated by the rolesCreate, rolesUpdate, and rolesDelete admin rights.

Role Restrictions come with a basic setup of model, field, comparison, filter value, and a permissions array. The permissions array lists the operations that are denied when a record matches — each entry is one of read, edit, create, delete; an operation listed there is blocked, and one left out is allowed. The comparison is one of eq, ne, gt, gte, lt, lte, in, nin. The roles UI shows these as model / action / path columns.

For example, let's say there were assets that should not be visible by competing contractors A and B. To prevent access to B's information do the following:

  • create a role called contractor A and add a Role Restriction with the following details:
  • set the model as feature to represent the map features
  • set a field with the information like owner
  • set a comparison like eq
  • set filter Value to Contractor B
  • add read, edit, create, delete to the denied permissions, meaning they cannot see it or change it.

Once complete, add the contractor A role to your Contractor A users (from each user's profile), and those users will not be able to see anything where the owner is Contractor B.

Using Admin Rights together with Role Restrictions

By default, all users other than the admin can see everything but not alter everything. Allowing write access broadly can be restricted to by records to define rigorous process controls offering some useful seperations:

  • By work stage (i.e. Preventing those who report work from seeing the quality assurance reports afterwards)
  • By asset (i.e. infrastructure like poles and ducts vs. active equipment and eletric cables are by others)
  • By physical and logical concepts (i.e. relationships like capacity and consumptions between offices vs. the location and characteristics of the offices themselves)

Customizing Authenticaiton and Authorization for new users

Modification of any of these settings will require the appSettingSchemasModify admin right on the user profile. This is granted by default to super admins upon access to the application, but may be shared by other admins. To see the admin rights a user has view their profile under users (http://your host/admin/users) and see Admin Rights.

Checking Admin Rights

The following may be customized to overide the (defaults):

  • Default roles for new users (the defaultRoles setting)

There is no "default admin rights" setting — new users start with no admin rights, which are then granted per user from their profile.