Once a user has been authenticated (see authentication), that user is granted or denied permissions for each protected object in the system using the user’s “permissions map” (a category-based matrix, for an example see Figure 297).
Depending on object type, permission meanings vary as follows:
By design, the UserService component enjoys a special permission scheme—and one that varies from the scheme described in this
section. See UserService security notes for details.
Each slot in any component is assigned to one of two permission levels, called operator and admin. This level is determined by whether the “Operator” config flag is set for that slot.
-
If set (checked), the slot can be accessed by a user with a minimum of operator-read permissions.
-
If cleared (unchecked), a user requires at least admin-Read permissions to access the slot.
With admin-Write permissions, you can see and change slot flags from the slot sheet of any component, as shown in Figure 267. By default, most slots are admin level (“out” is typically operator level).
To control user access from a permission level, six permissions are derived, as follows:
-
Operator-read — Allows the user to view operator-level information.
-
Operator-write — Allows the user to modify operator-level information (if not read-only).
-
Operator-invoke — Allows the user to view and invoke operator-level operations (actions).
-
Admin-Read — Allows the user to view admin-level information.
-
Admin-Write — Allows the user to modify admin-level information (if not read-only).
-
Admin-Invoke — Allows the user to view and invoke admin-level operations (actions).
When you assign a user’s permissions, higher-level permissions automatically “include” lower-level ones.
For example, as shown in Figure 268 if you enable admin-level write (W), admin-level read (R) is automatically enabled, as well as operator-level read and write (r and w).
Often, you may wish to grant a user permissions to components using categories not included in their parent components, such that permissions to a component’s “ancestor tree” are not explicitly granted. In this case, the system automatically grants “Operator-read” access to all “ancestor” components in the component tree. Otherwise, a user would be unable to navigate to target components in the Nav tree.
This “automatic ancestor permission” assignment is done by the station periodically, but you can force it at any time with a right-click “Update” action on the CategoryService.
Starting in AX-3.7 and in security patches for other release levels, basic changes occurred with file access to increase security.
A station’s config.bog file (and config.bog.backup files) are no longer accessible (even by super users) in the station’s File space. Note other station files and folders may
be “blacklisted” from remote station access, if needed. Additionally, any new station created using the New Station Wizard,
by default, has the entire station’s File space assigned to category index 2 (named “Admin”), whereas prior to AX-3.7 all
objects were assigned to category index 1. Users typically require operator-read permissions on station file folders like
^nav, ^px, ^images, ^html, and so on. However, permissions higher than “operator-read” on the Admin category should only be assigned to selected users
on a “as needed basis”.
Largely, permissions given to categories used by files and folders are “operator-keyed,” as follows:
-
Files
Files require operator-read access to view, and operator-write permissions for editing (if applicable). For instance, a user with operator-write permissions to an .html file can modify it using the Text File Editor in Workbench.
-
Folders
Folders (directories) require operator-read access to list and to copy child files, and operator-write access to create new (or delete existing) child files.
A few views for files require admin-write permissions to access, such as the Nav File Editor for a “nav file.” There are also other special case file permissions.
These additional rules apply to file system access from station access:
-
Files in any NiagaraAX module are automatically granted operator-read.
-
If a user is not a “super user,” all access outside of the station’s home directory is denied.
-
Admin-read rights are needed to see a Supervisor station’s
^provisioningNiagarafolder (written to by the Supervisor’s “Niagara Provisioning” mechanism).