HEAD Metamodel: Hierarchical, Extensible, Advanced, and Dynamic Access Control Metamodel for Dynamic and Heterogeneous Structures
Abstract
:1. Introduction
- Hybrid models, by means of combining features of two or more AC models, for example, hybrid RBAC/ABAC model [7];
- Extended AC models, by means of adding new component(s) to a model to enhance its features, for example, [8];
- Abstract AC models, by means of abstracting a model and adding new components to it, then deriving different instances of it, for example, [9];
- AC metamodels, by means of including all of the above, for example, [10].
- Proposing an advanced AC metamodel with generic, dynamic, and extensible characteristics; it can also be considered a foundation stone to solve other limitations in existing AC metamodels, including collaboration and interoperability between various models.
- Providing a solution for the need of component hierarchy in AC models (e.g., objects, actions, roles, categories, contexts, etc.).
- Developing a language to express AC requirements, and to serve as a basis for producing AC decisions for access requests.
- Providing a grammar language that is simple and flexible to appropriately express AC policy requirements.
- Assisting developers and security experts to include unified and generic components in designing secure ISs that conform to the organizational AC security policies.
2. Related Works
- They do not include all features of the common AC models, so they are not generic enough;
- They do not support the ability of defining new entities and building relationships between them in order to describe larger set of AC rules, for example, due to changing environmental conditions, so they are not dynamic enough to follow technology upgrades;
- They do not include the possibility of defining new components and attributes in addition to the defined ones, so they are not extensible and the defined policies cannot be extended;
- They do not support the feature of hierarchy for components;
- They do not handle or support the feature of collaboration and interoperability between the various AC models;
- They do not tackle the issue of migrating AC policies from one model to another.
3. Formalization of Access Control Policies
- Before check-in, each worker has to wear a face mask.
- The maximum number of visitors in each room is 15.
- Machine operators can only enter the labs during working hours.
3.1. Unifying Access Control Concepts of Heterogeneous Security Policies
- The DAC model includes subject, object, and action concepts.
- The MAC model includes subjects, object, security level, and operation concepts.
- The RBAC model includes subject, object, role, permission, and action concepts.
- The ABAC model includes subject attributes, object attributes, context attributes, condition, and action concepts.
- A set of concepts (and attributes) to describe subjects and objects.
- A set of concepts (and attributes) that describe the authorized subjects.
- A set of concepts (and attributes) that explain the different access rights.
- A set of concepts (and attributes) that set various constraints and conditions.
- A set of concepts (and attributes) that describe the context (environmental context) to access objects.
3.2. HEAD Metamodel
- It unifies the heterogeneous components of AC models.
- It is generic enough to include the common AC models and other models.
- It is dynamic and includes the feature of defining components (and attributes for all components).
- It is extensible since it allows extending the already derived AC models.
- It supports the hierarchy for any type of components.
3.2.1. Kernel Elements: HEAD Metamodel
- EXPLICIT (Ex): a set of explicit components that represent the real and the existing entities, such as subjects and objects in any organization or industry sector. The class EXPLICIT has a composition association with the sub-classes AUTHORIZATION UNIT and PROCEDURAL UNIT, which are the inheritance of the abstract IMPLICIT class.
- IMPLICIT (Im): a set of implicit components that represent the described components. For example, subjects are classified or assigned to some other component(s) (e.g., roles), or the processes or functions that can be performed (e.g., actions). Two other sub-classes that are inherited from the Implicit super-class are the AUTHORIZATION UNIT (AU) components and the PROCEDURAL UNIT (PU) components.
- -
- AUTHORIZATION UNIT (AU): a set of authorization units. It is a subclass which should be specialized to create specific authorization units (, sub-index i specifies the unit type), such as roles, categories, security levels, etc., to which some Ex units (e.g., subjects) can be assigned, An AU example is as follows:- au: role (manager, doctor, …)- au: category (age > 18, temperature < 38, …)Hence, AU includes role and category components
- -
- PROCEDURAL UNIT (PU): a set of procedural units. It is a subclass which should be specialized to create specific procedural units (, sub-index i specifies the unit type) such as actions, permissions, operations, etc., to which some Ex units (e.g., objects) can be assigned. In other words, it represents operations that can be performed by Ex units (e.g., subjects) on some other Ex units (e.g., objects), a PU example is as follows:- pu: action (read, write, …)- pu: operation (turn on/off, open, close, …)Hence, PU includes action and operation components.
- SETTING (St): a set of setting components. It represents the concepts that are included to have more accurate and regulated access to resources, for example, context, contextual conditions, constraints, etc. The setting components actually provide our metamodel with high flexibility and expressiveness. They could include other components (explicit, implicit, or/and other setting) to construct the needed expression(s). For example, A context expression and contextual conditions can be expressed in terms of AU, PU, Ex, and St components.
3.2.2. Hierarchies and Associations
3.2.3. Meta-Policy and Policy
- To define RBAC policy:
- -
- Ex = }
- -
- Im = }Hence,Meaning that a subject assigned to role has permission(s) to access object(s) and perform action(s).
- To define a hybrid MAC/RBAC policy:
- -
- Ex = }
- -
- Im = }Hence,Meaning that, subjects who are assigned to specific roles and security levels have permissions to access objects that are classified to some security levels and perform some actions.
Thus, the policy is expressed using model components, which are derived from the meta-components of meta-policy.
4. Defining the Grammar of HEAD Metamodel
- Lines 1 to 39: to instantiate the needed AC model(s) components, the hierarchies, and the attributes.
- -
- Lines 1 to 6: the block of defining all model components. ‘Metamodel’ is the root class for the definition of parser rules. The used keywords ‘policy’ and ‘end’, in line 3, are used to indicate the start and end of creating policy components. Note that our metamodel is able to create one or more policy types (e.g., MAC policy and RBAC policy). Each defined rule generates one decision (line 5).
- -
- Lines 7 to 9: the declaration of attribute(s) name(s) and datatype(s); also, arrays can be declared.
- -
- Lines 10 to 15: the definition of the policy name (e.g., RBAC) and the sub-blocks (inside the main block of policy) of the Ex, Im, and St components. To create a policy, at least one or more explicit/implicit element(s) must be declared; also, we could have zero or more setting element(s). To define the sub-block of Ex and St elements, the keywords ‘explicit’ and ‘setting’ are used, respectively, at the beginning, and ‘end’ at the end. Note that the ‘Implicit’ parser rule (line 13) has two elements, ‘AuthorizationUnit’ and ‘ProceduralUnit’ (lines 23 to 27).
- -
- Lines 16 to 18: the alternatives of attribute data types.
- -
- Lines 19 to 22: the creation of Ex components, their attributes, and their hierarchies.
- -
- Lines 23 to 27: the creation of sub-blocks of Im elements (AUs and PUs). The keywords ‘authorization’ and ‘procedural’ are used to indicate the beginning of each sub-block, and ‘end’ at the ending.
- -
- Lines 28 to 31: the creation of AU components, their attributes, and hierarchies.
- -
- Lines 32 to 35: the creation of PU components, their attributes, and hierarchies.
- -
- Lines 36 to 39: the creation of St components, their attributes, and hierarchies.
- -
- Note that attributes could be defined for all components, and an unlimited number of levels for components hierarchy can be created.
- Lines 40 to 63: to define a policy (set of rules), based on the instantiated components and attributes with the access request decision. Note that, using our grammar definition, rules (and hybrid rules) can be expressed in different ways, for example, a subject can access object(s) and perform an operation(s), or an object can be accessed by a subject(s) and perform an action(s).
- -
- Line 40: the parser rule ‘Decision’, is the beginning of specifying and expressing a rule which ends with a decision (‘–>’ id+=ID, line 59).
- -
- Line 41: after using the keyword ‘rule’ (line 4), some attributes can be created, for example, ruletype, rulenumber, etc.
- -
- Lines 42 and 44: the block of rule definition starts with an open curly braces ‘{’. A rule is started by specifying an Ex component (e.g., subject or object) and its attributes. In some models, explicit components are assigned to some AUs, for example, in RBAC subjects are assigned to roles, and in MAC subjects/objects are assigned to security levels. Note that Ex-AU assignment is optional ‘?’ in expressing a rule, depending on the expressed model (line 44).
- -
- Line 45: it is optional to define a nested block for a procedural unit, for example permission in RBAC, to express a policy.
- -
- Line 46: the beginning of expressing another nested block after specifying an Ex component and assigning it to some AU(s), or defining some PU(s).
- -
- Lines 47 to 49: same interpretation of lines 42 to 44. Hence, the beginning of a rule could be expressed as follows, for example:
- -
- A subject can access object(s)…
- -
- An object can be accessed by a subject(s)…
- -
- A subject assigned to a role has permission to access object(s)…
- -
- A subject assigned to a security level can access object(s) assigned to some security levels…
- -
- Lines 47 to 56: the sign ‘+’ in ‘)+’, line 56, indicates that what is included between lines 47 to 56 can be expressed more than once within a rule.
- -
- Lines 50 to 55: the start and end of a sub-block of specifying what PUs (e.g., actions) an Ex unit can perform. Note that it is optional to include some St (e.g., conditions) while expressing a rule. The sign ‘+’ in ‘)+’, line 54, indicates that what is included between lines 51 and 54 can be expressed more than once.
- -
- Line 57 to 59: closing the main block with some of opened sub-blocks.
- -
- Line 59: indicates the end of rule expression with the decision ID. Note that the sign ‘+’ in ‘)+’indicates that a set of rules can be defined within a policy.
5. Deriving Access Control Models
5.1. Generality
5.1.1. Discretionary Access Control Model (DAC)
5.1.2. Mandatory Access Control Model (MAC)
5.1.3. Role-Based Access Control Model (RBAC)
5.1.4. Attribute-Based Access Control Model (ABAC)
5.1.5. Hybrid Models
5.2. Dynamism
- Scenario 1: Assume that an RBAC model is already formulated to define a policy for an organization. Hereinafter, due to some organizational changes and updates, the following occurrs:
- Some users who are already assigned to certain roles need to be assigned, based on their roles, to security levels.
- Some other users now should be directly assigned to levels.
- Both users in (a) and (b) are only allowed to access some sensitive objects (e.g., documents), which are also classified into levels based on their sensitivity.
Hence, some of already defined rules must be updated, and new rules must be defined. Figure 18 is an example of how the HEAD grammar is dynamic. Lines 2 to 5 indicate the already defined RBAC entities (with the attributes), and lines 13 to 21 indicate the already defined RBAC rules. Lines 22 to 31 indicate that some RBAC rules are updated to express hybrid MAC/RBAC rules. As we can see, in line 24, some subjects who are assigned to some roles are now assigned to some security levels, and in line 26, some objects are assigned to some security levels. Lines 32 to 38 indicate the definition of new MAC rules. - Scenario 2: Assume that an ABAC model is already formulated, and the policy is already defined in an organization. Suppose that the organization has departments dept1, dept2, and dept3. However, due to some changing conditions, a new static and dynamic AC rules must be defined and others must be updated. The updated policy, due to new changing conditions, states the following:
- Dynamic rule: subjects (users) in dept2 and dept3 are not allowed to access some objects after three failed password attempts (assuming that another level of authentication is needed before accessing the objects).
- Static rule: some subjects in dept1 can determine what operations, (i) other subjects can perform, and (ii) some other subjects with the specific role can perform, on their objects.
Clearly, some already defined rules must also be updated, and new rules must be defined. As shown in Figure 19, the red and blue indicators refer to the modifications and the new expressions for rules. To answer the needed updates, in line 3, two additional attributes are defined as well as the attribute ‘countPW’ in line 8 to count the number of failed attempts while entering the password ‘PW’. Another St entity is instantiated named condition (line 9) to check the subject’s department and role based on (a) and (b) of the above policy updates. Lines 12 to 22 indicate that some ABAC rules are updated to answer the needed modifications in (a). As we can see, an action can be performed on an object if the following are true:- -
- The answer of condition (line 17) is true (the condition is true if the value of the dept attribute is equal to that of dept2 or dept3).
- -
- Another authentication level is verified by entering the correct password ‘PW’ and another condition (contextualCondition) must return true (contextualCondition is true if the value of ‘countPW’ is less than or equal to three).
Note that the condition is verified at a certain point in time, specifically when something occurs. Hence, this rule deals with the dynamic behavior of the subjects. Note that our grammar is able to express a rule in another way starting with the object. As well, to answer the requirements in (b)-(i) and (b)-(ii), a new rule is expressed in lines 24 to 37.- (i)
- An object with attribute type = type-value can be accessed by subjects with attribute address = address-value and perform some action act = act-value1, and some other action act = act-value2 if their dept = dept-value (dept1).
- (ii)
- An object with attribute type = type-value can be accessed by subjects with attribute address = address-value and perform some action act = act-value1, and some other action act = act-value2 if their dept = dept-value and their role = role-value.
5.3. Extensibility
5.4. Hierarchy of Entities
- -
- Creating a hierarchy of roles and objects in RBAC: assume that, after expressing an RBAC policy, an organization needs to update/define new rules that support the hierarchy of roles (two levels of hierarchy) and objects (three levels of hierarchy). In Figure 21a, in lines 2 to 4, we define three levels of object hierarchy: objectL1, objectL2, and objectL3. Note that L1, L2, and L3 are concatenated with the entity name to indicate the level number. In lines 6 to 7, two levels of role are defined (roleL1, and roleL2). In lines 14 to 28, the rule states the following:A subject with name = name-value assigned to roleL1 = role-value has permission to access an objectL1 = name-value and perform action act = act-value if condition is true, an objectL2 = name-value and perform action act = act-value, and an objectL3 = name-value and perform action act = act-value.In lines 30 to 39, a subject assigned to a role in second level of hierarchy can access an object(s) in a second level of hierarchy, and another object(s) in a third level of hierarchy. The rule states the following:A subject with name = name-value assigned to roleL2 = role-value has permission to access an objectL2 = name-value and perform action act = act-value, and an objectL3 = name-value and perform action act = act-value.Figure 21b, shows the defined entities/attributes, and the hierarchy of roles and objects. Note that if a subject is assigned to one or more roles, the expression could be written as follows:
6. Generating Policies: Examples and Illustrations
- Example 1—RBAC policy: The doctors Mark and Joe in a hospital can read and write patients’ prescriptions. The nurse Joyce is allowed to read these prescriptions.In this example we have three rules:
- Doctor Mark can read and write patients’ prescriptions.
- Doctor Joe can read and write patients’ prescriptions.
- The nurse Joyce can read patients’ prescriptions.
In Figure 22, we illustrate a concrete model instance for the RBAC policy example, which is instantiated from the derived RBAC model based on the HEAD metamodel. For the above policy, we have the following entities/classes:- -
- entities: subject (worker: name, dept, …), and object (prescription: details, …)
- -
- entities: role (rType, …)
- -
- entities: action (aType, …), permission (permId, …)
The generated RBAC policy in Figure 23 is modeled based on RBAC model, explained in Section 5.1.3. As shown in the figure, the model includes several elements, and the three rules are generated based on them.- Three subjects (with attribute name): Mark, Joe, and Joyce.
- One object (with attribute name): Prescription.
- Two roles (with attribute rType): Doctor, and Nurse.
- Two permission assignments (with attribute perm): DoctorPermission, and NursePermission.
- Two actions (with attribute aType): Read, and Write.
- Example 2—MAC/RBAC policy: In the clinics department of a hospital, the doctors Mark and Joe have a clearance level of “Top Secret” that is equal to the classification level of the object patient prescription. Hence, the doctors are allowed to read/write prescriptions. The nurse Joyce has the clearance level of “Secret” and can read patients’ prescriptions.In this example we have the following rules:
- Doctor Mark, whose clearance level is “Top Secret”, can read and write prescriptions that have a classification level equal to “Top Secret”.
- Doctor Joe, whose clearance level is “Top Secret”, can read and write prescriptions that have a classification level equal to “Top Secret”.
- Nurse Joyce, whose clearance level is “Secret”, can only read patients’ prescriptions.
In Figure 24, we illustrate a concrete model of hybrid MAC/RBAC policy example. Note that, in this example we use BIBA (developed by Kenneth J. Biba) as MAC variant. In the defined policy, some subjects are assigned to doctor and nurse roles. Subjects are permitted to read an object if their clearance level is ⩽ than the object’s classification level, and to write if it is greater than or equal (⩾). Note that if, for example, the clearance level for Doctor Joe is “secret", then he is only allowed to read patients’ prescriptions. Hence, we have the following entities/classes:- -
- E class(es): subject (worker: name, dept, …), and object (prescription: details)
- -
- AU class(es): role (rType, …), security level (level, …)
- -
- PU class(es): action (aType, …), permission (permId, …)
The generated MAC/RBAC policy in Figure 25 is modeled based on the hybrid MAC/RBAC model, explained in Section 5.1.5. As shown in the figure, the model includes several elements, and the three rules are defined based on them.- Three subjects (with attribute name): Mark, Joe, and Joyce.
- One object (with attribute name): Prescription.
- Two roles (with attribute rType): Doctor, and Nurse.
- Two security levels (with attribute level): Top secret, and Secret.
- Two permission assignments (with attribute perm): DoctorPermission, and NursePermission.
- Two actions (with attribute aType): Read, and Write.
7. Conclusions and Future Perspectives
Author Contributions
Funding
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Acknowledgments
Conflicts of Interest
Abbreviations
AC | Access Control |
IoT | Internet of Things |
HEAD | Hierarchical, Extensible, Advanced, and Dynamic |
DAC | Discretionary Access Control Model |
MAC | Mandatory Access Control Model |
RBAC | Role-based Access Control Model |
ABAC | Attribute-based Access Control Model |
IS | Information System |
HGABAC | Hierarchical Group and Attribute-based Access Control |
HoBAC | Higher-order Attribute-based Access Control |
CBAC | Category-based Access Control |
CSPM | Cloud Security and Privacy Metamodel |
WCMS | Web Content Management System |
E | Explicit |
I | Implicit |
AU | Authorization Unit |
PU | Procedural Unit |
S | Setting |
References
- Zhang, Y.; Nakanishi, R.; Sasabe, M.; Kasahara, S. Combining IOTA and Attribute-Based Encryption for Access Control in the Internet of Things. Sensors 2021, 21, 5053. [Google Scholar]
- Cruz-Piris, L.; Rivera, D.; Marsa-Maestre, I.; De La Hoz, E.; Velasco, J.R. Access control mechanism for IoT environments based on modelling communication procedures as resources. Sensors 2018, 18, 917. [Google Scholar] [CrossRef] [PubMed] [Green Version]
- Kalsoom, T.; Ramzan, N.; Ahmed, S.; Ur-Rehman, M. Advances in sensor technologies in the era of smart factory and industry 4.0. Sensors 2020, 20, 6783. [Google Scholar] [CrossRef] [PubMed]
- Kashmar, N.; Adda, M.; Atieh, M.; Ibrahim, H. Access Control in Cybersecurity and Social Media. Cybersécurité Médias Sociaux 2021, 69–105. [Google Scholar]
- Kashmar, N.; Adda, M.; Atieh, M.; Ibrahim, H. A review of access control metamodels. Procedia Comput. Sci. 2021, 184, 445–452. [Google Scholar] [CrossRef]
- Kashmar, N.; Adda, M.; Atieh, M. From Access Control Models to Access Control Metamodels: A Survey. In Future of Information and Communication Conference; Springer: Cham, Switzerland, 2019; pp. 892–911. [Google Scholar]
- Rajpoot, Q.M.; Jensen, C.D.; Krishnan, R. Attributes enhanced role-based access control model. In International Conference on Trust and Privacy in Digital Business; Springer: Cham, Switzerland, 2015; pp. 3–17. [Google Scholar]
- Servos, D.; Osborn, S.L. HGABAC: Towards a formal model of hierarchical attribute-based access control. In International Symposium on Foundations and Practice of Security; Springer: Cham, Switzerland, 2014; pp. 187–204. [Google Scholar]
- Aliane, L.; Adda, M. HoBAC: Toward a higher-order attribute-based access control model. Procedia Comput. Sci. 2019, 155, 303–310. [Google Scholar] [CrossRef]
- Kashmar, N.; Adda, M.; Atieh, M.; Ibrahim, H. Access control metamodel for policy specification and enforcement: From conception to formalization. Procedia Comput. Sci. 2021, 184, 887–892. [Google Scholar] [CrossRef]
- Kashmar, N.; Adda, M.; Ibrahim, H. Access Control Metamodels: Review, Critical Analysis, and Research Issues. J. Ubiquitous Syst. Pervasive Netw. 2021, 3. in press. [Google Scholar]
- Jaïdi, F.; Labbene Ayachi, F.; Bouhoula, A. A methodology and toolkit for deploying reliable security policies in critical infrastructures. Secur. Commun. Netw. 2018, 2018, 7142170. [Google Scholar] [CrossRef] [Green Version]
- Myrbakken, H.; Colomo-Palacios, R. DevSecOps: A multivocal literature review. In International Conference on Software Process Improvement and Capability Determination; Springer: Cham, Switzerland, 2017; pp. 17–29. [Google Scholar]
- Mao, R.; Zhang, H.; Dai, Q.; Huang, H.; Rong, G.; Shen, H.; Chen, L.; Lu, K. Preliminary findings about devsecops from grey literature. In Proceedings of the 2020 IEEE 20th International Conference on Software Quality, Reliability and Security (QRS), Macau, China, 11–14 December 2020; pp. 450–457. [Google Scholar]
- Hu, V.C.; Kuhn, D.R.; Ferraiolo, D.F.; Voas, J. Attribute-based access control. Computer 2015, 48, 85–88. [Google Scholar] [CrossRef]
- Sandhu, R.; Coyne, E.; Feinstein, H.; Role-Based, C.Y. Access control models. IEEE Comput. 2013, 29, 38–47. [Google Scholar] [CrossRef] [Green Version]
- Kashmar, N.; Adda, M.; Atieh, M.; Ibrahim, H. A new dynamic smart-AC model methodology to enforce access control policy in IoT layers. In Proceedings of the 2019 IEEE/ACM 1st International Workshop on Software Engineering Research & Practices for the Internet of Things (SERP4IoT), Montreal, QC, Canada, 25–31 May 2019; pp. 21–24. [Google Scholar]
- Sun, K.; Yin, L. Attribute-role-based hybrid access control in the internet of things. In Asia-Pacific Web Conference; Springer: Cham, Switzerland, 2014; pp. 333–343. [Google Scholar]
- Hasiba, B.A.; Kahloul, L.; Benharzallah, S. A new hybrid access control model for multi-domain systems. In Proceedings of the 2017 4th International Conference on Control, Decision and Information Technologies (CoDIT), Barcelona, Spain, 5–7 April 2017; pp. 0766–0771. [Google Scholar]
- Kuhn, D.R.; Coyne, E.J.; Weil, T.R. Adding attributes to role-based access control. Computer 2010, 43, 79–81. [Google Scholar] [CrossRef]
- Aftab, M.U.; Qin, Z.; Hundera, N.W.; Ariyo, O.; Son, N.T.; Dinh, T.V. Permission-based separation of duty in dynamic role-based access control model. Symmetry 2019, 11, 669. [Google Scholar] [CrossRef] [Green Version]
- Kim, S.; Kim, D.K.; Lu, L.; Song, E. Building hybrid access control by configuring RBAC and MAC features. Inf. Softw. Technol. 2014, 56, 763–792. [Google Scholar] [CrossRef]
- Li, H.; Wang, S.; Tian, X.; Wei, W.; Sun, C. A survey of extended role-based access control in cloud computing. In Proceedings of the 4th International Conference on Computer Engineering and Networks; Springer: Cham, Switzerland, 2015; pp. 821–831. [Google Scholar]
- Nguyen, P.H.; Nain, G.; Klein, J.; Mouelhi, T.; Le Traon, Y. Model-driven adaptive delegation. In AOSD’13: Proceedings of the 12th Annual International Conference on Aspect-Oriented Software Development; ACM: New York, NY, USA, 2013; pp. 61–72. [Google Scholar]
- Adda, M.; Aliane, L. HoBAC: Fundamentals, principles, and policies. J. Ambient. Intell. Humaniz. Comput. 2020, 11, 5927–5941. [Google Scholar] [CrossRef]
- Slimani, N.; Khambhammettu, H.; Adi, K.; Logrippo, L. UACML: Unified access control modeling language. In Proceedings of the 2011 4th IFIP International Conference on New Technologies, Mobility and Security, Paris, France, 7–10 February 2011; pp. 1–8. [Google Scholar]
- Barker, S. The next 700 access control models or a unifying meta-model? In SACMAT’09: Proceedings of the 14th ACM symposium on Access Control Models and Technologies; ACM: New York, NY, USA, 2009; pp. 187–196. [Google Scholar]
- Bertolissi, C.; Fernández, M. A metamodel of access control for distributed environments: Applications and properties. Inf. Comput. 2014, 238, 187–207. [Google Scholar] [CrossRef] [Green Version]
- Abd-Ali, J.; El Guemhioui, K.; Logrippo, L. A Metamodel for Hybrid Access Control Policies. J. Softw. 2015, 10, 784–797. [Google Scholar] [CrossRef] [Green Version]
- Alves, S.; Degtyarev, A.; Fernández, M. Access control and obligations in the category-based metamodel: A rewrite-based semantics. In International Symposium on Logic-Based Program Synthesis and Transformation; Springer: Cham, Switzerland, 2014; pp. 148–163. [Google Scholar]
- Khamadja, S.; Adi, K.; Logrippo, L. Designing flexible access control models for the cloud. In Proceedings of the 6th International Conference on Security of Information and Networks, Aksaray, Turkey, 26–28 November 2013; pp. 225–232. [Google Scholar]
- Xia, T.; Washizaki, H.; Kato, T.; Kaiya, H.; Ogata, S.; Fernandez, E.B.; Kanuka, H.; Yoshino, M.; Yamamoto, D.; Okubo, T.; et al. Cloud security and privacy metamodel. In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development, Funchal, Portugal, 22–24 January 2018; pp. 379–386. [Google Scholar]
- Martínez, S.; Garcia-Alfaro, J.; Cuppens, F.; Cuppens-Boulahia, N.; Cabot, J. Towards an access-control metamodel for web content management systems. In International Conference on Web Engineering; Springer: Cham, Switzerland, 2013; pp. 148–155. [Google Scholar]
- Kashmar, N.; Adda, M.; Atieh, M.; Ibrahim, H. Deriving access control models based on generic and dynamic metamodel architecture: Industrial use case. Procedia Comput. Sci. 2020, 177, 162–169. [Google Scholar] [CrossRef]
- Kashmar, N.; Adda, M.; Atieh, M.; Ibrahim, H. Smart-ac: A new framework concept for modeling access control policy. Procedia Comput. Sci. 2019, 155, 417–424. [Google Scholar] [CrossRef]
Metamodeling Layers | Details | |
---|---|---|
Description | Elements | |
Metamodel | Describes the models to be instantiated | explicit, implicit, authorization unit, procedural unit, setting |
Model | Metamodel instance, e.g., RBAC model, ABAC model… | subject, object, role, action, permission… |
System | Model instance, e.g., RBAC policy, hybrid policy… | Alice, Bob, manager, nurse, prescription, device… |
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |
© 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Share and Cite
Kashmar, N.; Adda, M.; Ibrahim, H. HEAD Metamodel: Hierarchical, Extensible, Advanced, and Dynamic Access Control Metamodel for Dynamic and Heterogeneous Structures. Sensors 2021, 21, 6507. https://doi.org/10.3390/s21196507
Kashmar N, Adda M, Ibrahim H. HEAD Metamodel: Hierarchical, Extensible, Advanced, and Dynamic Access Control Metamodel for Dynamic and Heterogeneous Structures. Sensors. 2021; 21(19):6507. https://doi.org/10.3390/s21196507
Chicago/Turabian StyleKashmar, Nadine, Mehdi Adda, and Hussein Ibrahim. 2021. "HEAD Metamodel: Hierarchical, Extensible, Advanced, and Dynamic Access Control Metamodel for Dynamic and Heterogeneous Structures" Sensors 21, no. 19: 6507. https://doi.org/10.3390/s21196507
APA StyleKashmar, N., Adda, M., & Ibrahim, H. (2021). HEAD Metamodel: Hierarchical, Extensible, Advanced, and Dynamic Access Control Metamodel for Dynamic and Heterogeneous Structures. Sensors, 21(19), 6507. https://doi.org/10.3390/s21196507