## 5 Case Study 1--ITMI: Non-IoT
### The Solution: HEAD Metamodel
#### 5.2.2 Phase 2: Generating Policies
Figure 7: Case Study 1: (a) A sample of Xtend notation for Explicit entities; (b) the generated Java code for the subject entities. define constraints under which policy state data are obligated to change. For example, in (1) when the director confirms the ProjectDetails information, the manager would not be able to {u, d} this information; another example in (3) expresses an obligation due to some context where the adviser is not allowed to {u, d} information in Requirements container if he logged into the system via a public network or if the current date is greater than the end date of NQR project; also in (4, 5, and 6) users of Groups A, B, and C are not allowed to {w, u, d} information of containers GrpATskRslt, GrpBTskRslt, and GrpCTskRslt during the non-business hours and before and after the start and end of project dates. Figure 10 shows a sample of Java output to configure the required AC policy. The green text demonstrates the configuration of the subject and object entities and attributes that is performed by a system administrator based on the schema from Figure 9, indicating the hierarchical relationship between the object containers. For example, the object 'nqrDuration' is assigned_to 'ProjectDetails' container, the object 'Labs' has a hierarchical relation with (or includes) the 'Machines' container, and so on. After configuring the policy elements, Figure 11a shows a sample of the generated Cypher statements to create policy class (PC), e.g., create (:PC {industry: TTMI'}); users (U), e.g., create (:U {sname: 'Roy'}); objects (O), e.g., create (:O {oname: 'Labs'}), etc. Figure 11b shows examples of Cypher statements representing O-OA and OA-OA assignments, and OA hierarchies. For example, the first statement is to create 'ProjectDetails' node, then assign 'nqrDuration' node to the created node. The second and third statements means that the object 'ProjectDetails' at the root level 'include' the 'Requirements' and 'ProjectTasks' nodes which are at the second level of object hierarchy. The remaining statements mean that 'ProjectTasks' node at level 2 'include' the nodes 'GrpATskRslt', 'GrpBTskRslt', and 'GrpCTskRslt' which are at the third level. Note that the semicolon ',' indicates the end of a statement. Figure 9: Case Study 1: NGAC Policy Configuration. The Cypher statements in Figure 11c expresses the association relationships that define the access rights for some UAs (e.g., Director, Manager...) over some OAs (e.g., FinancialDetails, ProjectDetails...). For example, lines 1-3 and lines 7-9 match the UAs 'Director' and 'Manager', and the OAs 'FinancialDetails', 'ProjectDetails', and 'ProjectTasks'. Then, lines 5-6 express that the director with DirPermission is able to perform {r, w, u, d} operations on 'FinancialDetails' and {d, c} on 'ProjectDetails', and lines 11-12 express that the manager with ManPermission is able to perform {r, w, u} operations on 'ProjectDetails' as long as the information is not confirmed by the director (pr)Confirm = 'false'). Since the basic elements of NGAC are U, O, UA, OA, and assignment/association relationships, we configure the constraints and contextual constraints as properties in the association relationship. As a result of configuring the NGAC policy and injecting the generated Cypher statements into Neo4j, we can display the NGAC policy graph in Figure 12.  
Figure 10: Case Study 1: A sample of Java output with the configuration of subjects, objects, etc. Figure 11: Case Study 1: sample of Cypher statements for (**a**) PC, U, and O nodes; (**b**) O–OA assignments and object hierarchies; (**c**) access rights as AU-OA associations.