ACLs are the mechanism used to enforce access control. This section describes how ACLs are derived from the access control policy for a domain. The next section describes how ACLs work.

An ACL is generated for each object type, state, and domain. A given object is associated with the ACL whose domain, type, and state match that of the object. For example, all WTDocument objects of a given life cycle state, within a given domain, are associated with the same ACL. In addition, this ACL is different from the ACL associated with WTPart objects that belong to the same domain.

An ACL for an object is obtained by combining all rules that apply to the object’s type, state, and domain. To make this definition precise, it is necessary to describe how rules are combined, and when a rule applies to a type.

A rule is applicable to a given type when the object type referred to in the access control rule is the type itself or one of its ancestor types. For example, a rule that applies to the WTDocument type also applies to incident reports if IncidentReport is a subtype of WTDocument.

Rules that apply to a type are combined by merging rules that have the same permission type and participant. The merge is performed by calculating the union of all permissions within the consequents.

For example, consider the combination of the following rules:

The combination of these rules produces the following ACL entries for incident reports in the InWork state in the /Parts domain in the Bike Production context: