## 5 Case Study 1--ITMI: Non-IoT
### The Solution: HEAD Metamodel
#### 5.2.1 Phase 1: Deriving Models  
In this section, we investigate the best AC model that fits the AC requirements of this case study. Due to the above E\({}_{\rm x}\), I\({}_{\rm m}\), and S\({}_{\rm t}\) entities, we have the possibilities:  
* RBAC model: RBAC entities are subject, object, role, permission, and action. Users are assigned to roles and groups, and in some situations we have attributes and environmental conditions. Hence, the RBAC model is not enough to satisfy the AC requirements, since we cannot find all the necessary entities.
* ABAC model: ABAC entities are subject, object, action, and environmental (context) attributes. ITMI users are assigned to roles and groups. Therefore, with the ABAC model, the RBAC model should be considered, in addition to the group entity since users are assigned to roles and/or groups.
* Hybrid model: the notion of role reflects the importance of considering the RBAC model; the notion of attributes and the need to express dynamic AC rules reflect the importance of taking into account the ABAC model; also the group entity with its attributes imposes the need not to restrict the solution to RBAC or ABAC models only. Hence, the solution should consider future entities that need to be created/added due to upgrades.  
Therefore, our solution in this case is to derive a hybrid model based on user-groups, RBAC, and ABAC. Using the DSL of the HEAD metamodel the formal user-groups, RBAC, and ABAC hybrid model can be derived by first instantiating the needed entities of E\({}_{\text{x}}\), AU, PU, and S\({}_{\text{t}}\), then expressing the rules as shown in Figure 6. In Figure 6a:  
* line 1: the specification of policy model/class.
* lines 2 to 10: the block of creating E\({}_{\text{x}}\) entities, starts and ends with the keywords explicit and end. Line 3: the creation of subject entity with the attribute(s). Lines 4 to 9: four levels of objects are created to represent the hierarchy of resources. We actually have three levels of object hierarchy, but since we use NGAC as an enforcement framework we create additional level to have four levels. 'object1' level expresses the main objects assigned to different object containers, and the other three levels are defined to represent the hierarchy object containers.
* lines 12 to 21: the block of creating AU entities, starts and ends with the keywords authorization and end. Line 13: the creation of group entity with the attribute(s). Lines 14 to 20: four levels of role hierarchy are created. For example, role1 refers to the director, role2 refers to the manager, etc.
* Lines 23 to 26: the block of creating PU entities, starts and ends with the keywords procedural and end. Line 24: the creation of permission entity with the needed attribute(s). Line 25: the creation of action entity with the attribute(s).
* Lines 28 to 33: the block of creating S\({}_{\text{t}}\) entities, starts and ends with the keywords setting and end. Lines 29 and 30: the creation of context entity with the context attribute(s). Lines 31 and 32: the creation of constraint entity with the attribute(s).  
Moreover, in Figure 6b we provide examples of three possible rule expressions:  
* Lines 39 to 47: this rule expression is, for example, to express access rights for users who are assigned to the first-level of role hierarchy (e.g., director) and implicitly connected with the actions associated with their role (e.g., manager) without the administrator having to explicitly list the manager actions on objects, and this is also applied at the lower levels of hierarchy.
* Lines 48 to 58: to express, for example, the rule for users designated as assigned to the second-level of role hierarchy who are implicitly associated with their role(s) and perform some actions on objects with some constraints.
* Lines 59 to 73: the rule is expressed, for example, for users with lower-level roles, and who are also assigned to a specific group, to perform certain actions on certain objects of a certain level in a particular context under certain constraints.