About Access Control Lists
This section provides a brief description of the way in which ACLs are derived from the access control policies for domains, and describes how they work to enforce access control.
When you create an access control rule, you specify the rule antecedent and the rule consequent:
• The rule antecedent comprises the following parts:
◦ The domain.
◦ The object type, determines which rules within an access policy apply to a specific object.
◦ The life cycle state, which identifies the life cycle phase that an object must be in for the permissions to apply. If the object type is not a life cycle managed type, then the state is not applicable and only rules with life cycle state set to ALL apply.
• The rule consequent comprises the following parts:
◦ A participant, which is a user, a user-defined group, a system group, a role, or an organization. A user can be a member of more than one group or role.
◦ Whether the rules is for the participant or all participants except the specified participant.
◦ Associated permissions.
◦ Whether permissions are granted, denied, or absolutely denied.
A rule for all except a participant treats the participant as a group whose members are all participants except the following:
• Administrator user
• Selected user
• Users in the selected group, dynamic role, or organization
For example, a rule could be written specifying that all participants except the Administrators group are denied Delete permission for Parts in the Released state. In this case, all participants who are not members of the Administrators group are unable to delete parts when they are in the specified state.
The roles defined in the Policy Administration utility can be categorized as pseudo roles or dynamic roles:
• A rule defined for the pseudo role of OWNER specifies permissions that apply to the owner of an ownable object.
• A rule defined for the pseudo role of ALL specifies permissions that apply to all participants. When calculating ACLs, this role is handled like a group.
• A rule defined for a dynamic role specifies permissions that apply to corresponding system groups that are associated with context teams in which the roles are used. When ACLs are derived for a domain, the dynamic roles resolve to the system groups associated with the context of the domain. If a specific context does not have some of the roles used in the rules defined for dynamic roles, then the corresponding rules are ignored. For example, assume that a rule is defined for the context team Designer role in the Default domain of the organization. If the Designer role is not used in a specific application context where the context has inherited the rules from the Default organization domain, then the rule defined for the context team Designer role is ignored. See
Using Dynamic Roles to Centralize the Administration of Access Control Rules.
You can create access control rules for some or all of the object types within a domain. Together, these rules constitute the access control policy for the domain.
An ACL is created on demand for each rule antecedent. An ACL is derived from the policy for a domain and its ancestor domains, and is composed of multiple ACL entries. Each ACL entry contains a set of permissions associated with a participant. Each ACL entry grants (+), denies (-), or absolutely denies (!) permissions to the associated participant.
To improve performance, when ACLs are calculated, they are cached so they can be quickly retrieved the next time a user requests access to a particular object.