## 3 HEAD Metamodel  
In [15], we propose a hierarchical, extensible, advanced, and dynamic AC metamodel, named HEAD metamodel. This metamodel has advanced features compared to other AC metamodels proposed in the literature. Its distinct design and the new opportunities it opens in the domain are described in [20]. In this section, we briefly explain its metamodels (or meta-classes) and features to show how it can be employed to derive the needed AC models for two case studies (explained in Sections 5 and 6) inspired by ITMI's non-IoT and IoT computing environments, then generate the needed AC rules to enforce them. The meta-components (or meta-classes) of HEAD metamodel are the EXPLICIT (E\({}_{\mathrm{x}}\)), IMPLICIT (I\({}_{\mathrm{m}}\)), and SETTING (S\({}_{\mathrm{t}}\)). As shown in Figure 2[15], E\({}_{\mathrm{x}}\) represents entities/classes within an organization or industry sector, such as subjects and objects. I\({}_{\mathrm{m}}\) represents the described entities/classes. I\({}_{\mathrm{m}}\) includes AUTHORIZATION UNIT (AU) entities/classes such as roles, security levels, etc., and PROCEDURAL UNIT (PU) entities/classes such as actions, permissions, etc. S\({}_{\mathrm{t}}\) represents the concepts needed to have more regulated access to resources, such as entities/classes of context, contextual conditions, etc. The relationships between HEAD metamodel components can be described as follows:  
* between E\({}_{\mathrm{x}}\) and AU is to allow assigning zero or many (0.*), for example, subjects to roles, groups, etc.;
* between AU and PU, and PU and E\({}_{\mathrm{x}}\) is to describe which AUs (e.g., groups) can perform zero or many (0.*) PUs (e.g., actions) on some other E\({}_{\mathrm{x}}\) (e.g., objects);
* E\({}_{\mathrm{x}}\) and I\({}_{\mathrm{m}}\) could have zero or many (0.*) S\({}_{\mathrm{t}}\) (e.g., condition) to fulfill access requests;
* the self-association edge on each meta-class is to allow formulating hybrid models by associating, for example, AUs with other AUs, PUs with other PUs, etc.;
* the aggregation association for each meta-class allows the creation of hierarchies of the derived component(s).  
The DSL of the HEAD metamodel is explained with examples in [15], it can be used to derive various AC models (common AC, hybrid AC, and other models). For example, to derive the MAC model, subject and object classes must be instantiated from E\({}_{\mathrm{x}}\), security level must be instantiated from AU, and operation class must be instantiated from PU. Another example, is the RBAC model where subject and object classes must be derived from E\({}_{\mathrm{x}}\), role class from AU, and permission and action classes from PU. Using the HEAD metamodel, access to resources is determined by the attributes of the defined entities in the access request including subject, object, action, context, etc. It allows enforcing complex AC policies that involve an arbitrary combination of attributes with static, dynamic, and relationship values. Also, it allows deriving models of high granularity for access policies, fitting the various needs of AC requirements. This extends beyond the proposed AC metamodels in the literature [15; 20].