Setting access control : System Architect Catalog Manager : Access control levels
  
Access control levels
System Architect Catalog Manager provides two levels of access control to encyclopedia objects. The first level, role-based access control (RBAC), controls permission to object types. It is a general level of control that makes no distinction among objects of the same type. If you grant a permission to use case diagrams then you grant permission to all use case diagrams. Instance Level Access Control (ILAC) provides a higher, more specific level of access control, where you can select different permissions for objects of the same type. For example, you can grant the “read” permission to one use case diagram, and also grant the “write” permission to a different use case diagram.
Role-based access control
Role-based access control requires the three-way relationship to be established for a user or user group, encyclopedia, or workspace, and a role.
A user or a group gains those permissions by having those roles assigned to them.
Users get to perform their roles on the encyclopedias to which they are assigned.
Users can also be granted access to encyclopedias by their being members of user groups which are involved in the same sort of three-way relationship.
Roles can have role expressions where they can optionally inherit or disinherit permissions of other roles in a specific sequence.
Summing of permissions
When a user opens an encyclopedia using System Architect, the permissions the user is known to have are the sum of the permissions of the roles involved in User-Encyclopedia-Role relations involving the active user or a group that the active user is a member of.
The permissions of an individual role are a sum of the permissions assigned directly to that role and the permissions of roles in the role expressions; these can either be inherited or disinherited as explained below.
Each permission value that can be ticked or checked indicates an ‘on’ state.
In the case of menu permissions, the possible values are Enabled and Visible (ignore ‘Override role expressions’ for the moment).
In an inherit operation, each state is ORed (a binary OR operation); therefore, the inherit operation is always additive in that it will only enable a menu option or make a menu option visible since 0 (‘off’) OR 1 (‘on’) is 1 and 1 OR 1 is 1.
In a disinherit operation, each state is ANDed with the inverse or NOT of the disinherited state.
If the ‘Override role expressions’ option is set, the locally assigned permission values will not be changed by role expressions when summing permissions.
The ‘Override role expressions’ state is not inherited.
Note regarding workspaces
If a three-way relationship is not set up for the workspace that is loaded then the parent workspace is checked for, and until there is no more parent workspace, the three-way relationships for the host encyclopedia are checked. There is no inheritance of permission settings from an encyclopedia or workspace to a child workspace.
Permission is also necessary at the encyclopedia level to allow the encyclopedia to be opened.
Instance level access control
Instance level access control works on top of role-based Access Control. But ILAC has additional requirements; you must set the ILAC state for encyclopedias (see Setting ILAC state for encyclopedias) in the System Architect Catalog Manager to use the instance level access control. You can use the ILAC group restrictions feature to restrict unwarranted access by a user to certain encyclopedias. To know more about ILAC group restrictions, see Setting ILAC group restrictions for encyclopedias.
See also
System Architect Catalog Manager