About hierarchical security roles
A user can belong to more than one security role. Security roles can also belong to other security roles and form a hierarchy. If you add a security role to another, the role you add becomes a parent or a child role. A role inherits privileges from a parent, and passes privileges to a child.
To remove an inherited privilege from a role, the administrator must remove the privilege from every parent role that has the privilege.
iHub does not support using nested roles with pass-through security.
Figure 3‑2 shows three security roles. The Sales role is the parent role of Sales Managers, and Sales Managers is the parent role of Sales VP. Sales Managers inherits privileges from Sales. Sales VP inherits privileges from Sales Managers and Sales.
Figure 3‑2 Viewing a security roles hierarchy
Table 3‑1 shows the assigned privileges that the Sales, Sales Managers, and Sales VP roles have on a folder, /Public/Sales, and on a design file, /Public/Sales/Sales Invoice.
Table 3‑1 Privileges assigned to roles on a folder and a file
Security role | /Public/Sales | /Public/Sales/Sales Invoice |
Sales | Read | None |
Sales Managers | Write | Visible, execute |
Sales VP | None | None |
As an example, Alan Barron belongs to the Sales VP role. To execute Sales Invoice and write the output to the /Public/Sales/ folder, Alan Barron requires the following privileges:
Execute and either read, secure read, or visible privilege on Sales Invoice
Write and either visible, secure read, or read privilege on the /Public/Sales folder
As a member of the Sales VP role, Alan Barron inherits:
Write privilege on the /Public/Sales folder from the Sales Managers role
Read privilege on the /Public/Sales folder from the Sales role.
Visible and execute privileges on Sales Invoice from the Sales Managers role.
Alan Barron inherits all the privileges he needs to execute Sales Invoice and write the output to the /Public/Sales folder.
