How ACLs Work

Permissions for a participant defined in one access control rule may conflict with other permissions defined in other rules. For example, you could define an access control rule that gives everyone in the Team 1 group delete permission for all incident reports belonging to the /Acme domain when they are in the Under Review state. However, in another access control rule, you could explicitly deny user Audrey.Carmen that permission, despite her membership in Team 1. In such cases, the ACL mechanism calculates the net permissions for a participant.

The following table provides a quick reference to how permissions work together. A full explanation can be found after the table.

The net permissions for a participant are calculated based on the following rules:

• Each participant (user, user-defined group, system group, or organization) can have at most one grant ACL entry, one deny ACL entry, and one absolute deny ACL entry; that is, multiple ACL entries with the same permission type are not allowed for any participant. Each entry specifies the set of permissions that are to be granted, denied, or absolutely denied. Pseudo roles can have at most one grant ACL entry and one deny ACL entry. Absolute deny permissions cannot be specified for pseudo roles.

Dynamic roles resolve into specific system groups before ACLs are generated. See Considerations When Resolving Dynamic Roles in Rules.

• Permissions granted, denied, or absolutely denied to all participants except a specified participant are treated like permissions specified for a group whose members include all users except the Administrator user, the selected user, or users in the selected group, dynamic role, or organization.

• If there is no ACL entry for a particular user, group, pseudo role, or organization, that participant has the null permission set. In effect, having a null permission set denies the participant access to the object.

• If there is a grant entry that gives a participant a permission and a deny or absolute deny entry for the participant and the same permission, the permission is not granted.

• Permissions that are explicitly granted (+) to the pseudo role OWNER override any permissions denied (-) to the user that is the owner of the ownable object through a deny entry for the individual user or for a group or organization to which the user belongs.

• Permissions that are explicitly granted (+) to the pseudo role OWNER do not override any permissions absolutely denied (!) to the user that is the owner of the ownable object through an absolute deny entry for the individual user or for a group or organization to which the user belongs.

• Permissions that are explicitly granted (+) to the user that is the owner of an ownable object or to a group or organization to which the user belongs are not overridden by any permissions denied (-) to the pseudo role OWNER. Permissions denied to the pseudo role OWNER are ignored.

• Permissions that are explicitly granted (+) for an individual user override permissions denied (-) for that user's group or organization permissions as well as permissions denied for the pseudo role ALL. For example, user ReneN is a member of Group 1. According to an access control rule for the Acme domain, all members of Group 1 are denied modify permission to incident reports in the Under Review life cycle state. However, if another access rule explicitly grants ReneN permission to modify incident reports, then, ReneN is granted the modify permission, despite membership in Group 1.

• Permissions absolutely denied (!) or denied (-) to a user override permissions granted (+) for that user’s group or organization. For example, according to an access control rule for the Acme domain, all members of Group 1 are granted Modify permission for change notices in the Reviewed life cycle state. Another access rule denies ReneN Modify permission for change notices. Even though ReneN is a member of Group 1, ReneN is denied Modify permission.

• Permissions absolutely denied (!) to a group or organization cannot be overridden by explicitly granting (+) permissions to an individual user who is a member of that group or organization. For example, according to an access control rule for the Acme domain, all members of Group 1 are absolutely denied the administrative permission to change requests in the Completed life cycle state. Even if another access rule explicitly grants ReneN permission to administer change requests, ReneN is denied the administrative permission.

• For a given user, the net group grant permission set is the union of all the grant permissions of each group and organization to which the user belongs. This includes permissions granted for the pseudo role ALL. For example, if user ReneN belongs to Group 1, Group 2, and Group 3, ReneN’s grant group permission set includes all of the permissions granted to those groups.

• For a given user, the net group deny permission set is the union of all the deny permissions (-) of each group and organization to which the user belongs. This includes permissions denied for the pseudo role ALL. For example, if user ReneN belongs to Group 1, Group 2, and Group 3, ReneN’s deny group permission set includes all of the permissions denied to those groups.

• For a given user, the net group absolute deny permission set is the union of all the absolute deny permissions (!) of each group and organization to which the user belongs. For example, if user ReneN belongs to Group1, Group 2, and Group 3, ReneN’s deny group permission set includes all of the permission denied to those groups. Permissions cannot be absolutely denied for the pseudo role ALL.

When the permissions are calculated for the ACL, the grant, deny, and absolute deny permission sets for user ReneN are merged to determine access rights. For example, as a member of Group 1, ReneN is granted read permission to all incident reports in the Under Review life cycle state in the /Acme domain. However, ReneN is also a member of Group 2, which is denied read access to incident reports in that domain. When calculated, ReneN's permission to read incident reports is set to null for the /Acme domain, so ReneN is denied access.

The following table provides some further examples of permission calculation. Assume you, the administrator, are creating an access control policy for several domains. One of the users you have identified, Ann, belongs to group G1, but not G2. If you assign permissions as shown in the table, Ann's resulting permissions are identified in the last column.

	G1 Permissions	All Except G2 Permissions	Union of G1 and All Except G2	Individual Permissions	Resulting Permissions
+ - !	Modify (M) Null set Null set	Create (C) Null set Null set	(C) + (M) Null set Null set	Delete (D) + Administrative (A) Null set Null set	(C) + (M) + (D) + (A)
+ - !	(M) (D) (A)	(C) (M) Null set	(C) + (M) (D) + (M) (A)	(D) Null set Null set	(C) + (D)
+ - !	(M) + (A) (D) Null set	(D) (C) Null set	(M) + (A) + (D) (C) + (D) Null set	(C) (M) (A)	(C)
+ - !	(M) Null set Null set	(C) Null set (A)	(M) + (C) Null set (A)	(D) + (A) (M) Null set	(C) + (D)

When you have defined the access control rules for domains, all of the instances of the object type of a particular state, and belonging to the same domain for which you have created rules, share an ACL. This association between the ACL and the object type, state, and domain is preserved thereafter. When a participant attempts to access an object (for example, to view it or modify it), the associated ACL is retrieved, and the policy is enforced. Once an ACL is calculated, it is cached so it can be retrieved quickly for the next access request.

For example, assume that within the /Acme domain, user Audrey.Carmen is a member of a group that has Read and Delete permission for all objects of the type WTObject that are in the Closed state. She is also a member of a group that has Modify permission for all incident reports within the /Acme/Support domain in the Closed state, where IncidentReport is a subtype of WTObject. However, there is another access control rule within the /Acme domain for Audrey.Carmen as an individual user, that explicitly denies her Delete permission for incident reports in the Closed state.

The following shows the ACL entry for Audrey.Carmen that is associated with incident reports in the Closed state within the /Acme/Support domain:

When this ACL entry was derived from the access control policies for the /, /Acme, and /Acme/Support domains, Audrey.Carmen was given Read and Modify permissions. Because IncidentReport is a subtype of WTObject, Audrey's Read and Delete permissions for objects of type WTObject also apply to incident reports. However, because there is another access control rule that explicitly denies her Delete permission for incident reports in the Closed state, her resulting permissions are Read and Modify, and she is not able to delete objects of that type and state combination belonging to the /Acme/Support domain.