AX1329

About subsystems and roles

Subsystems can be used in conjunction with roles. You can assign a user to a subsystem, and then assign the user to one or more roles to grant security permissions. These permissions are then limited by the subsystem boundaries.

There are two ways that you can use roles with subsystems:

• You can assign subsystem users to "global" roles, meaning standard roles that don't belong to a subsystem. These roles can contain users that belong to any subsystem. The role permissions are inherited "as is" by the user and then the user's effective permissions are restricted by their assigned subsystem.

• You can assign a role to a subsystem, and then assign users in the subsystem to the role. In this case, only users who also belong to the subsystem can belong to the role. Also, the role permissions are restricted by the assigned subsystem before the user inherits the permissions.

Subsystem-specific roles are recommended if users may belong to multiple subsystems, due to the small but crucial difference in how role inheritance and subsystem restrictions interact. Also, subsystem administrators can create and edit subsystem-specific roles, which provides the subsystem administrator with greater control over the use of roles with their subsystem users. When using global roles, subsystem administrators can only assign users to the role, they cannot edit the role or see the role's permissions.

Role inheritance and subsystems

If each user only belongs to one subsystem, then there is no difference in the effective permissions when users inherit permissions from global roles or from subsystem-specific roles. However, if a user can belong to multiple subsystems, then the effective permissions can vary depending on which type of role is used.

To illustrate this difference, consider the following plan file filter settings for a file group:

In this configuration, it doesn't matter whether the role is global or whether it belongs to the subsystem. In both cases, the user will ultimately be restricted to plan files that are assigned to Facility 5. If the role is global, then the subsystem restriction of Facility 5 will be applied to the user after the role inheritance. If the role belongs to a subsystem, then the Facility 5 restriction will be applied to the role before the permissions are inherited. Either way, the end result of the effective permission is the same.

Now consider what can happen if the role is global and the user belongs to two subsystems instead of just one:

In this configuration, the user inherits the permission from the global role before the subsystem restrictions are applied to the user. So the user's starting permission is All Plan Files. Because the user's multiple subsystem restrictions are combined using OR, the ultimate subsystem restriction is Dept.Facility=5 OR All Plan Files (which effectively means no restriction—the combined subsystem maximum permission allows access to all plan files). Together with the inherited role permission, this means the user has access to all plan files.

The organization may have intended the user to have access to all plan files. The user belongs to Subsystem 2 and that subsystem allows access to all plan files, so it is a valid result if the user is assigned to a role that grants access to all plan files. However, a potential issue may arise if the role assignment was made by the Subsystem 1 administrator. This subsystem administrator may not know that the user also belongs to Subsystem 2 and/or may not know that Subsystem 2 has a maximum permission of All Plan Files. The Subsystem 1 administrator can only consider the impact of his or her subsystem's restrictions, which would limit the user to plan files from Facility 5. The granting of all plan files via the Subsystem 2 maximum permission may be unintentional.

So if subsystem administrators are managing role assignments and users can belong to multiple subsystems, the only way to ensure that permissions are limited by each respective subsystem is to use subsystem-specific roles instead of global roles. For example, consider the following configuration where the user belongs to multiple subsystems and is assigned to subsystem-specific roles:

Now the role filters are limited by the subsystem restrictions before the user inherits permissions from the roles. This gets resolved as follows:

• Subsystem 1 role permission of All Plan Files is restricted by the Subsystem 1 maximum permission of Dept.Facility=5. The user can access only those plan files that belong to Facility 5.

• Subsystem 2 role permission of No Access needs no further resolution—the user is not granted access to any plan files via this subsystem.

• So even though the user's combined subsystem restriction is the same as in the previous example, this is no longer an issue because the role permissions are restricted by their respective subsystems before being inherited by the user. In this case this means the user is only granted the plan file access from the Subsystem 1 role, meaning the user only has access to plan files for Facility 5.

Now imagine the same permissions except that the role configured permission for Subsystem 2 is Dept.VP='Smith' instead of No Access. Now the user's effective permission is as follows: