Permissions
Permissions are a collection of pre-defined functionality and operations that can be assigned to users granted access to certain workflow and document, and configuration management tasks. The set of assigned permissions determines each user’s access to the available functionality. If a user is not granted the permission, they are not able to complete the task.
All configuration management tasks, and certain workflow and document tasks, require particular pre-defined permissions that may be either allowed or denied to particular principals; groups and users. If a principal is not granted the permission, they are not able to complete the task. For example, checking out locked files requires the FetchRevision and Lock permissions.
It is also important to understand that the application you use to administer ACLs also has an ACL itself to control who has access to update the security permissions. The Authorization Administration ACL is independent from the ACLs used for configuration management. You can also create control ACLs for other ACLs as required.
By default, all permissions are shipped as enabled for a principal group called everyone.
For more information on available permissions, see Workflow and Document Permissions and Configuration Management Permissions.
Permission Inheritance
In this access control system, permissions are (by default) inherited from their parent ACL, whether that is the mks:aa:mks management ACL, a product-level ACL (mks:im, mks:si), or an ACL specific to configuration management (for example, a project, subproject, or member ACL).
The PTC RV&S server queries the ACL database for the user’s access permissions working upwards through the ACL name space structure from the archive ACL level to the top (global) level to determine whether the user has the required permission to perform the requested operation.
When a user performs an operation, the PTC RV&S server checks the ACLs for appropriate permissions for the requesting user and specified command. When checking permissions in the ACLs, two areas are checked:
• principal type (user or group)
• scope (archive, project, or global)
When the PTC RV&S server checks the permissions, it first tries to find the most specific ACL for the target user, and then searches for more general ACLs. The following diagram shows the path the PTC RV&S server takes when checking its permissions.
The most specific type of permission is an archive ACL with the principal defined as a user (section 1 in the diagram). After this, the server moves on to any archive ACLs where the principal is defined as a group (section 2 in the diagram). It then checks for any project permissions with the principal defined as a user (section 3), and so on.
Permission Conditions
Permissions are always in one of three conditions:
• Allowed
Principal is allowed to perform the requested operation.
• Denied
Principal is not allowed to perform the requested operation.
• Cleared
Effectively an unset permission and considered as denied to the principal. A cleared permission can still be explicitly allowed through another principal or through a parent ACL.
The server always uses the most specific permission it finds in the ACL hierarchy. For example, the allowed and denied permissions are more specific than a cleared permission.
It is important to note the distinction between clearing and denying a permission. Based on inheritance, an explicitly denied permission takes precedence, even if that permission is allowed through another principal. When you clear a permission, that permission can still be explicitly allowed through another principal or through a parent ACL.
When performing an ACL check, the PTC RV&S server searches for the existence of either an allowed or a denied permission at each of the levels. Once this is found, the server stops checking permissions and either performs the operation as requested by the user (in the case of an allowed permission) or sends an appropriate error message (in the case of a denied permission).
When configuring your ACLs, you also have the option to clear a permission. If you do not explicitly set a permission for an operation, the permission is considered to be clear (or unspecified) by the PTC RV&S server. This allows you to define permissions at various levels.
• Example
You can globally allow all of your groups the CheckIn permission but then deny CheckIn for one group for a specific project. This method allows you to open up your allowed permission structure and then restrict permissions only on certain levels. The same approach works in reverse where permissions are restricted at a global level and then only granted on other levels where needed.
If the PTC RV&S server finds both an allowed and a denied permission at the same level, then the denied permission takes precedence. For example, a user is a member of two groups that are both listed in a project ACL. When the PTC RV&S Server checks the group principal at the project level, it finds one group is allowed to perform the operation while the other is denied. In this case, because a denied permission takes precedence, the user is denied permission to perform the operation.
Dev Path Permissions
Using the Inherit Permissions function, you can also enable or disable permission inheritance for individual development path ACLs. Settings on individual development path ACLs override the global Dev Path Inheritance setting for the selected development path.
If you select a development path ACL and set Inherit Permissions to true, the target development path ACL inherits its permissions from the project ACL. If set to false, the selected development path inherits its permissions from the top level mks:si ACL. For detailed procedures on creating a development path ACL, see “Dev Path Permissions”.
When Inherit Permissions is set to true or when global Dev Path Inheritance is set to true, permissions are inherited from the master project in the tree. If no ACLs are set in the master project, permissions resolve to the top level mks:si ACL. Therefore, if no project ACLs are set and permission inheritance is set to true, permissions resolve to the top level mks:si ACL.
When Inherit Permissions is set to false, permissions are inherited from the top level mks:si ACL.
For more information on setting permission inheritance for development paths, see “Dev Path Permissions”.
Resolution of Permission Conflicts
In cases where a user is identified as a principal with his or her own permissions and is also part of a group that is granted permissions, it is important to understand how any permission conflicts are resolved.
Each ACL entry specifies the set of permissions that are to be allowed (if positive) or denied (if negative). A principal can have at most one positive ACL entry and one negative entry, that is, multiple positive or negative ACL entries for the same permission are not allowed for any principal. All defined permissions take precedence over inherited permissions.
In resolving ACL permissions, any time a permission is explicitly specified for a user principal that permission takes precedence over his or her inclusion in a group. Individual permissions always override permissions of the group(s) the individual belongs to. Therefore, individual negative permissions (specific denial of permissions) override the positive permissions of the group, and individual positive permissions override the negative permissions of the group. For example, a user—Patrick Molinas—is allowed the CreateProject permission through the user principal for pmolinas, but is denied the CreateProject permission through his membership in the group principal for Developers. Because the permissions of the individual principal override the permissions of the group principal, Patrick is allowed the CreateProject permission.
In resolving a conflict between groups, negative permissions take precedence. If a principal is allowed a permission in one group but denied that same permission in another group, the conflict is resolved by denying the permission.
The permission set for the principal is then inherited from the parent ACL. If the root ACL is checked and offers no explicit positive or negative entry to apply to the principal, then the principal is considered to have an empty permission set for the resolved ACL, which in turn defaults to a denied permission.
Key factors for permissions include the following:
• Permissions are always in one of three conditions: allowed, denied, or cleared.
• The server always uses the most specific permission it finds in the ACL hierarchy. For example, the allowed and denied permissions are more specific than a cleared permission.
• Defined permissions take precedence over inherited permissions.
• Based on inheritance, an explicitly denied permission takes precedence, even if that permission is allowed through another principal. When you clear a permission, that permission can still be explicitly allowed through another principal or through a parent ACL.
• A permission that is explicitly specified for a user principal takes precedence over his or her inclusion in a group. A permission assigned to an individual always overrides the permissions of the group the individual belongs to.
• A principal can have at most one positive ACL entry and one negative entry. Multiple positive or negative ACL entries for the same permission are not allowed for any principal.
• If there is no entry for a particular principal, then the principal is considered to have an empty permission set for that ACL. The permission set for the principal is then inherited from the parent ACL.
• In resolving a conflict between groups, negative permissions take precedence. If a principal is allowed a permission in one group but denied that same permission in another group, the conflict is resolved by denying the permission.