Formal description of HOrBAC model

Companies’ information systems are regu-larly exposed to internal attacks perpetrated by users who have been granted access to the system. Discretionary, mandatory, role-based and organization-based access control models do not guarantee optimal protec-tion against these attacks because these models trust in users. Therefore, they are unable to protect the system against attacks carried out by authenticated users, especially the super user who can carry out any type of internal attack on information system’s data. The ob-jective of this paper is to propose a model that excludes any trust in users. To do so, our model extends the OrBAC (Organization Based Access Control) model by integrating two concepts: the organizational hierarchy and the redundant authentication. The model thus implemented oﬀers a hierarchical and redundant access control to data and processing in an information system based on zero trust in users.


IJIS manuscript No.
(will be inserted by the editor)

Formal description of HOrBAC model
Martin Benoît Azanguezet Quimatio · Fidèle Tsognong · Marcellin Julius Nkenlifack the date of receipt and acceptance should be inserted later Abstract Companies' information systems are regularly exposed to internal attacks perpetrated by users who have been granted access to the system. Discretionary, mandatory, role-based and organization-based access control models do not guarantee optimal protection against these attacks because these models trust in users. Therefore, they are unable to protect the system against attacks carried out by authenticated users, especially the super user who can carry out any type of internal attack on information system's data. The objective of this paper is to propose a model that excludes any trust in users. To do so, our model extends the Or-BAC (Organization Based Access Control) model by integrating two concepts: the organizational hierarchy and the redundant authentication. The model thus implemented offers a hierarchical and redundant access control to data and processing in an information system based on zero trust in users.

Introduction
Access control to data and processing in information systems is one of the unsolved problems to date with regard to the internal attacks identified in companies [1]. It is the process of mediating every request to resources and data maintained by a system and determining whether the request should be granted or denied [2,3]. . The discretionary access model (DAC) [4] limits access to objects based on the identity of their owners. Each user can transmit (indirectly or directly) his rights to any other user. This poses a problem of uncontrollable propagation of rights. The mandatory access control model (MAC) [5] is based on the hierarchy defined by security levels. Security levels are assigned to users and objects, and users can only access objects with a security level lower or equal to their own in the hierarchy. In the MAC model, access is strictly controlled by the administrator. Although this mechanism allows to define a robust security system, the administration of this model becomes very cumbersome when scaling up. To solve this problem, the role-based access control model (RBAC) [6] assigns permissions to roles, users become members of the appropriate roles and inherit the permissions granted to those roles. However, RBAC has been criticized for being static and for its hierarchy not conforming to the real hierarchy of organizations. The Organization-Based Access Control model (OrBAC) [7] takes the concepts of RBAC, incorporates the concept of organization and context, and extends the notion of permissions to include obligations, recommendations and prohibitions. Numerous extensions of RBAC and OrBAC models have been proposed to address other access control issues [7,8,9]. But none of these extensions protects the information system (IS) against internal attacks, especially those carried out by the super user (administrator) of the system. Indeed, all these models trust in users, and particularly the super user who has all the privileges on the whole IS. The latter can use his rights to carry out malicious activities that are very difficult to counter in real time. This is why the super user account is a prime target for malicious users looking to perpetrate attacks.
Some works propose user activity monitoring (UAM) techniques [10,11]. These techniques involve frequently auditing employee activities in the IS and analyzing the audit data to detect possible attacks. But like all previous models, they detect attacks after the fact because they are unable to monitor the suspicious actions of authenticated users in real time. The access control model based on organization's hierarchy and redundant authentication (HOrBAC) that we formalize aims to control access to data and processing for all users in the IS, including the super user or the DBA (database administrator), in order to prevent attacks and not to observe them. This model is based on two fundamental concepts: -The organizational hierarchy. This model uses a descending n-ary tree to represent the structure of an organization. This tree is structured in three parts. The root, the internal nodes and the leaves. The root represents the administrative unit with all rights over the rest of the organization. The internal nodes represent the administrative units that have control and supervision rights over the activities of the leaves nodes, which represent the operational units. These operational units model the employees in the organization. This new structuring of the organization reveals two types of roles, the administrative role and the operational role. -Redundant authentication. This concept models the real-time interactive control of all users' actions, by imposing an authentication to each of these actions. To achieve this, we consider each user action as a request to the hierarchy, waiting for validation. To implement this concept of request validation, two algorithms are proposed and grouped in the concept of digital parafer.
These concepts allow to propose an interactive access control model based on zero trust in users and which models the real organizational structure and the administration of the organizations' information systems. This paper proposes a formal description of our model using UML diagrams and first order logic. The formal language we propose focuses only on permissions in order to avoid conflicts related to the existence of prohibition policies [12,13]. This paper is organized as follows: the second section presents related works, the third section presents our access control model based on organizational hierarchy and redundant authentication. The fourth section provides the formal description of the proposed model and the specification of security rules. The fifth section presents a case study and the sixth section explains the prototype project.

Related Works
Following RBAC [6], many models have been proposed to address limitations such as access contexts, fine-grained access control, interoperability between organizations. Anas Abou El Kalam et al [7] proposed the organizationbased access control (OrBAC) to specify contextual rules related to permissions, prohibitions, obligations and recommendations. OrBAC extends the role-based access control model by adding the concepts of organization, activity, view and context to express security rules independently of their implementation. In the same logic, many OrBAC extensions have been proposed with the organization as a central concept. Anas Abou El Kalam et al. [14] proposed the multi-organization-based access control model (Multi-OrBAC) for collaborative, heterogeneous and distributive systems. Frédéric Cuppens et al. [15] proposed the Organization-to-Organization model (O2O) based on OrBAC to manage security policy interoperability. Vincent C. Hu et al. [16] proposed the attributebased access control model (ABAC) to provide finedgrained access control. Some researches combined ABAC and RBAC models to have more flexibility [17,18,19].
History-Based Access Control (HBAC) grants or declines access by evaluating the history of activities of the inquiring party that includes behaviour, time between requests and content of requests. A.N Ravari et al. [20] proposed a Generalized Temporal History Based Access Control (GTHBAC) which enhances the specification of user-defined authorization rules by constraining time interval and temporal expression over users' history of accesses.
Wenrong Zeng et al. [21] proposed Content-Based Access control model (CBAC) for content-centric information sharing in order to prevent misuse of the privileges by users. CBAC is expected to be deployed on top of RBAC or Multi-level Security (MLS), in the application scenarios where RBAC and MLS will give excessive access rights. The access decision is based on the content similarity.
But none of these models take into account the hierarchy of organizations. These models consider the role hierarchy instead of the organizational hierarchy. Therefore, the role of "Director" in a hospital, for example, will inherit all the rights and privileges of the subordinate roles, whereas operationally the Director does not play all these roles. That is why root users or database administrators (DBAs) inherit all rights in an information system, which technically places them above their superiors in the central administration.

Hierarchical organization-based access control model -HOrBAC
The HOrBAC model we formalize is based on organizational functional hierarchy and excludes the principle of trusting in users (zero trust). In addition to the concepts of organization, activity, context and view defined in OrBAC, we introduce the concepts of administrative unit, operational unit, employees, request, resource and digital parafer to model the organizational hierarchy and redundant authentication. The notion of permission is divided into administrative and operational permissions. Similarly, we add a new "type" attribute to the role concept to distinguish administrative roles from operational roles in an organization.

Administrative Unit
It models the set of controlling or supervising activities that are grouped into a role and used to administer operational units or other administrative units. It is represented by an internal node in the hierarchical tree of an organization. The figure(1) shows an example of a 3-level organization and the figure(2) shows the UML class diagram of the organisation functional hierarchy. The units a, b, c are administrative units and the units d, e, f, g in gray color are operational units. The unit a without parent is called root unit.

Operational Unit
It models the set of related IS state transformation activities grouped into a role and allowing employees to perform basic actions on IS resources. It is represented by a leaf node in the hierarchical tree of an organization.

Employee
It models all physical personnel with an operational role in the organization. It replaces the concept of subject in previous models, which expressed both real subjects (employees) and virtual subjects (users existing only in the organization's database, with no real and unique relationship with a physical employee). Our model implements a bijection between the employees and the users created in the IS.

Resource
It models the passive entities of the organization (file, folder, database, ...). It replaces the object entity in the previous models, because the concept of object creates confusion between subjects and the resources they manipulate.

Relations between concepts
In this section, we describe the relationships (mapping) added or modified on the OrBAC model.

Employs
One operational unit employs several employees. We use the relationship Employs to model this concept ( Figure 3).

Appoints
One employee is appoints to an administrative unit. We use the relationship Appoints to model this concept ( Figure 4).

Administrate
Several units (operational, administrative) are administered by one administrative unit. We will use the relationship Administrate to model this concept ( Figure  5).

Uses
A resource can be used in several views of an organization. We use the Uses relationship to model this concept ( Figure 6).

Defines
We reformulate the definition of the context as described in OrBAC to take into account the concepts of Employee and Resource that we have introduced in our model ( Figure 7).

High-level permissions
High-level permissions are applied to abstract entities: Organization, Administrative Unit, Operational Unit, Activity, View, Context. In particular, this model is composed of two high-level permissions: operational permissions and administrative permissions. It is at this level that the treatment modes must be specified.

Assignment of operational permissions
We use the relationship Operational-Permission to assign permissions to an operational unit allowing it to perform activities on views ( Figure 8).

Assignment of administrative permissions
We use the relationship Administrative-Permission to assign permissions to an administrative unit allowing it to control the activities of subordinate units, as shown in Figure 9.

Request
It models the set of actions of an employee on one or more resources of the organization in a given context. A request may or may not require control and approval from the hierarchy. We use the treatment mode property which can be real time for requests requiring no hierarchical control and deferred time for requests requiring control and approval from the hierarchical chain. When the treatment mode associated with a request is deferred time, its processing works according to the Four Eyes principle [22] with several levels of validation. This process has the particularity of being transparent to the issuing employee and the associated action is only executed if the last superior gives a favourable opinion.

Status of a request:
A request can be in progress, processed or archived. The diagram in the figure (10) models a request. Concrete permissions are low-level permissions that are applied to concrete entities, namely: Employee, Resource and Action. We define two main types of concrete permissions: the permission to initiate a request and the permission to manage a request.

Permission to initiate a request
The concrete permission for an employee to initiate an action on a resource is noted as CanInitRequest ( Figure  11). Such a permission can only directly change the state of the IS in a real-time mode.

Permission to manage a request
The concrete permission allowing a hierarchical superior to manage a request emit by an employee on a resource is noted CanManageRequest (Figure 12). This permission gives its owner the right to validate or reject a request.

Redundant authentication
We distinguish two types of access: access to the system and access to resources. By redundant authentication 1 , we mean that users are authenticated when accessing the system and each time they want to perform critical actions. The second authentication is performed by the users hierarchical superiors, who check whether the actions they are performing are legitimate. We use this principle to defeat attacks that rely on vectors (emails, shared files, downloaded files from unknown sources, infected removable disks, etc.) to use the privileges of the current user to attack the target machine. These attacks act undercover users and abuse the accesses they have received in order to perform illegitimate actions in the system. These are usually critical actions that users are not used to perform in daily life, such as creating a new user account, encrypting data, deleting important data, stealing data (copying and transferring to an unknown organization), locking data, etc. In reality, these attacks have malicious programs that try to perform bad actions during the user's session, which assumes that the user is already logged in. Therefore, the first authentication to the system is thwarted. By authenticating the user at each critical action (a kind of redundancy since the user is already authenticated for the first time) we can defeat these types of attacks. Nowadays, these attacks are numerous and cause a lot of damage to companies, in particular: Ransomewares [25,26].

Digital parafer
This section describes the concept of digital parafer that we propose and that works as a reference monitor on 1 In the field of databases, redundancy consists in having several copies of the same data in the database. In security, this concept is used to secure access to data at several levels in order to reduce the scope of attacks [23]. The invention [24] uses this concept to secure access to cloud resources by combining several identity providers.
the whole organizational tree in order to control the emission of requests and hierarchical treatments. This concept assumes that all the activities of the employees are considered as requests. It consists of two processes: the emission process and the treatment one. The figure 14 gives an overview of the structure of the digital parafer system.

Initializing the digital parafer
This phase consists of initializing the security store by creating organizational units, registering employees in their respective units, creating views and resources, creating activities and actions, defining administrative and operational permissions with their respective contexts and treatment modes.

Request emission process
It controls the emission phase of requests initiated by an employee (Figure 15). This process puts all requests whose treatment mode is deferred on hold.

Request treatment process
This process allows line managers to validate or reject a request issued by an employee. In the case of validation, the request is executed and changes the state of the IS, otherwise it is cancelled ( Figure 16).

Life cycle of a request
As defined in our previous article [27], a request is an action issued by an employee on a resource in a given context. When a request is issued, if the associated treatment mode is real time, it is directly executed in the  system. If the associated treatment mode is deferred, it triggers a hierarchical treatment chain. When the last superior in this chain approves (it is assumed that the last hierarchical superior has the last decision), the request is executed, if he rejects the request, it is cancelled. The treatment done by the intermediate superiors are only transitory treatments allowing the last superior of this chain to make good decisions. Each request has the identifier and the opinion of each superior who processed it so that at each level its history can be traced. The figure 17 shows the life cycle of a request. The implementation at the database level is done using triggers on the tables that one wants to secure.

Logical description of our model
In this section we give the logical formalism of our model. The language described here extends the one proposed for OrBAC formalism using our concepts.

Proposed Language
The formalism we propose is based on the first-order language L. From this language we can easily express the entities and relationships of HOrBAC model described in Figure (13). Each expression of L contains symbols from a particular vocabulary classified into four groups: constant symbols, individual variables, relationship symbols, and function symbols.

Constant symbols
The constant symbols correspond to the instances of the classes in Figure 13 such as organisation, Work Employee, Resource, Action, Operational Unit, Administrative Unit, View, Activity, Request, and Context. For example CBC Bank is a constant of type organisation, Jacques is constant of type WorkEmployee.

Individual variables and relationship symbols
In the L language, variables are noted by words beginning with lower-case letters. There are individual variables for each entity class. The relationship symbols in L will be denoted by words beginning with uppercase letters corresponding to the relationships in our metamodel diagram.
Each relationship symbol P is considered as a relationship type. According to our classes diagram we have the following relationship symbols: -Employs is a relationship symbol of type (organisation, Work Employee, Operational Unit), which maps an employee to his operational unit among an organisation. -Appoints is a relationship symbol of type (organisation, Work Employee, Administrative Unit), which maps an employee to his administrative unit among an organisation. -Administrate is a relationship symbol of type (Organization, Unit, Administrative Unit); this means that in an organization, a unit (operational or administrative) is administered by an administrative unit. -Uses is a relationship symbol of type (organisation, Resource, View); which means that in an organisation a resource is uses in a view. -Consider is a relationship symbol of type (organisation, Action, Activity); which means that in an organisation an action is considered as part of an activity. Actions are basics operations like read, write, select, update, get, put, clone, push, commit, depending of the system which is implemented. As stated in OrBAC, activities are concepts used to categorize actions which have the same objectives. Activity can be modify, consult, activate, cancel, create, delete, erase, download, load, etc and they are independent of the implementation and files systems. -Define is a relationship symbol of type (organisation, Work Employee, Resource, Action, Context); which means that in an organisation a context is defined for an employee to operate on a resource. -Operational Permission is a relationship symbol of type (organisation, Operational Unit, Activity, View, Context, Treatment Mode); which means that an organisation grants a permission to an operational unit to perform an activity on a view with respect to a given context and treatment mode. -Administrative-Permission is a relationship symbol of type (organisation, Administrative Unit, Activity, View, Context, Treatment Mode); which means that an organisation grants a permission to an administrative unit to approve an activity performed by an operational unit with respect to a given context an treatment mode.

Functions
A function symbol permits to derive informations about entities. Let consider the given sets: E the set of employees, U the set of organisational units (administrative and operational), R the set of resources, V the set of views, A the set of activities and O the set of actions (operations). We have particular functions in our language: unit : E → U , return the unit of an employee; -type : U → {Operational, Administrative}, return the type of a unit; -superior : E → E, return the direct superior of an employee; -hierarchy : U → U , return the direct hierarchy of a unit; -subunits : U → 2 U , return the children a of unit; -employees : U → 2 E , return the employees of a unit; -resources : V → 2 R , return the resources of a view; -actions : A → 2 O , return the actions which are part of an activity; -depth : U → N , return the depth of the sub-tree rooted by the given unit.

Atomic Formulas
Atomic formulas represent facts.

Specifying Policies in HOrBAC
We describe below how operating rules can be specified via our language.

Hierarchy order
In OrBAC the notion of hierarchy is reduced to the inheritance of objects and materialized by prefixed predicates of the keyword Sub. We go beyond this inheritance between entities and defines a hierarchy of control over employees and organisational units. The notion of sub-organisation does not exist in our model, but we consider sub-views and sub-activities as defined in Or-BAC model as they contribute to reduce administration workload.
The hierarchical order in an organisation is a hierarchy of superiority between units and between employees. To simplify we will use the up arrow symbol (↑) to represent hierarchy between units(resp employees), u1 ↑ u2 means u1 units is superior to u2. For employees e1 ↑ e2 means e1 is the hierarchical superior of e2.
In our language the hierarchical order between the units of an organisation is represented by the predicate isSuperior. Through polymorphism we use the same predicate to characterize the hierarchical superiority relationship between employees.
Between employees, the relation e1 ↑ e2 is deduced by the following rule: ∀ org: Organisation, e1, e2: Employee This means that e1 ↑ e2 is true in any organization org if e2 works in a unit administered by the e1's unit.
The hierarchy order (↑) relation is asymmetric, not transitive and not reflexive:

Context and constraints
The context allows one to know the concrete circumstance in which a permission is granted to an employee [28] . The mostly used contexts are time-based, locationbased and devices-based. Contexts can be declared in our language using Define relation. For instance: Defines(CBC Bank, HR Manager, salary-file, write, atoffice), mean that the human resource manager of CBC bank can only write to the salary-file at office.
Constraints are expressed in our model by restrictions on cardinalities and attribute domains: -There is a single employee appointed to the head of an administrative unit; -An operational unit is placed under one and only one administrative unit; -An Administrative Unit is subordinate to another administrative Unit; -There is only one non-subordinated administrative unit, which is the root unit; The head of the organisation works in this root unit; -The emitter of a request cannot be the approver; -In some organisations, multiple job-holding is prohibited and each employee is assigned to only one organisational unit.

Security rules specification
A safety rule reflects how the security status is related to the different permissions that exist in the system. There are two low level types of permissions in our model: can suggest and can treat which can also be understood as can emit a request and can approve a request. In the proposed language, these two concrete permissions can be derived as follows: if an organisation org, in the context c, grants the operational permission to the unit ou to initiate the activity q in the view v, with the treatment mode m, if org Employs the work employee e to unit ou, if org Uses the resource r in the view v , if org Considers that the action a is part of the activity q and if within the organisation org the context c is true between e, a and r, then the employee e can perform the action a on the resource r with or without superior approval (depending on the associated treatment mode m). This result in the following rule: If the organisation org, in the context c, grants administrative permission to the administrative unit au to approve activity q performs by organisational unit ou, on view v, with the treatment mode m, if e ↑ emittere', if org uses the resource r in view v, if org considers the action a as part of the activity q and if within the organisation org the context c is true between e, a, r, then employee e can approve the request to perform action a on resource r issued by the emitter e' with or without further hierarchical approval (depending on the associated treatment mode m). So we have the following rule: Def ines(org, e ′ , a, r, c))). (3)

Synthesis
Given an organization org, let's consider the following sets: E the finite set of employees, O the set of actions By analogy to the analysis work done by [29,30,31], for all these relationships, the ones that change constantly due to the evolution of an organization are the assignment of employees to units and the assignment of access contexts to employees. Other relationships such as hierarchical order, assignment of actions to activities, assignment of resources to views, and permissions rarely change.
Let consider an access request The evaluation complexity of σ(ar i ) is given by: The set of access requests is given by: The total number of access requests that can be emitted in the system is: To evaluate the completeness of the model it is necessary to verify that the system covers each ar i ∈ Q a , since any non-permitted action is forbidden, for that it is necessary to evaluate the following formula: The evaluation time for access requests coverage is given by: We consider τ σ as the evaluation time for a single access request ar i since it doesn't depend on i.
The Binary Decision Diagram (BDD) of σ(ar i ) is given on figure(18) . Let consider a treatment request sent by the employee e ′ i and  The evaluation complexity of σ ′ (tr i ) is given by: The Binary Decision Diagram (BDD) of σ ′ (ar i ) is given on figure (19).
The treatment chain of an access request ar i is the set of treatment requests tr j made by the sender's superiors in sequence, ordered by time. Let consider the function which gives the treatment chain of an access request ar i and Q t the set of treatment requests.
We use tr t j to specify the j th treatment request with it associated time t, meaning that the j th request has been sent at t.
The evaluation time of the treatment chain of an access request ar i is the sum of the evaluation time of each treatment request belonging to the chain. Let τ δ(ari) the evaluation time of the treatment chain of an access request ar i .
When the treatment mode of an access request ar i is deferred, it becomes mandatory to evaluate it final status before execution in the system. The final status of an access request (outcome of the request) depends on it treatment mode and the outcome of each treatment request belonging to δ(ar i ). Let ρ be the method used to combine the outcomes in order to determine the final status, γ(ar i ) the final status of the access request ar i .
The set of request outcomes is: The set of combining methods is: Combining methods are used to avoid outcomes conflicts, the semantic is given below: (a) With lhd the outcome of the access request to consider is the outcome of the last treatment request in the chain.
Ex. γ lhd (V, V, U , R) <t = R The BDD diagram of γ lhd (δ(ar i )) for |δ(ar i )| = 4 is given by the figure (20). (b) With mhd: the outcome of an access request is the overriding decision for its treatment requests. In the case of equiprobability the lhd algorithm is used.
The BDD diagram of γ mhd (ar i ) for |δ(ar i )| = 4 is given by the figure(21).  We only give these two algorithms, however the combining algorithms allow for voting decisions and may vary depending on the applications.

Overview of the administration model
The administration model defines who and how to manage units, permissions and the hierarchy between units. Contrary to ARBAC(Administration model of RBAC) [32], AdOrBAC(Administration model of OrBAC) [33] and the administration model of ABAC [34] where the super-user has all the rights, we propose a cooperative administration which will be a negotiation between the administrator and his superior. The administration of our model works according to the same principles as our model: any action is carried out in the system on the basis of request. Our idea is to reduce the powers of the super-administrator which is a point of failure for the previous administration models. We define below the prerequisites.
Pre-requisite 1 Let org be an organisation and E the set of its employees, to perform the hierarchical access control in org, E must respect the following constraint: Pre-requisite 2 The permissions to emit and process a request are mutually exclusives.
As defined for ARBAC and AdOrBAC, administering a model means managing administration views. In our case we have the following views: AEU (assignment of employees to units), APU (assign permissions to units), AUH (Inter-Unit Hierarchy Management). For implementation within an organization, to ensure control over the requests of users, when they send requests after having authenticated themselves, we check if the sender is the only employee in the organisation, if so the only possible action he can perform in the system is to create the root unit and appoint an employee who will be his superior, this is done directly without the need for hierarchical validation. If the administrator is not the only employee in the organization, the request is executed following the HOrBAC model.

Case study
In this section, we show how our model is used to express access control in a sample organization. In this case we consider a bank organization and few resources as shown by Figures 22 and 23. Here we translate the L language given above in Prolog.

Units to units mapping
The following facts define units hierarchy.

Employees to units assignment
Employees are assigned to their units using the following facts.

Resources to views mapping
Here views are databases, bank-DB-tables, security-DBtables and Applications. Resources to views mapping are given below.

Actions to activities mapping
Here activities are add, display, delete, activate, modify, save, view, open, authenticate. The following facts map actions to activities. We give few actions in order to simplify.

Contexts mapping
Here we consider three contexts as example: at-office, working-time and owner. The following facts define contexts.

High level permissions assignment
Sample permissions assignment are given below.

Hierarchy order between units
The rules below check the hierarchy order relation between units.

Hierarchy order between employees
The rules below check the hierarchy order between employees.

Policies interrogation
The rules below derived low levels permissions from high level ones. We add context C and treatment mode M for logic purpose. MotOrBAC [35] has been developed to administrate and simulate security policies based on OrBAC model. Our model has been implemented as a part of an open source identity provider project name's horbac-idp which is described and managed throw Jira plateform 2 . The main features of the project are : authentication, manage accounts, manage organizations, manage units, manage employees, manage actions and activities, manage resources and views, manage contexts and permissions. For testing purpose we implement a permissions helper feature to check and troubleshoot the can-init-request and can-manage-request low level permissions. The server part of the project is implemented as restful apis in java using Spring Boot framework and the web interface is implemented in javascript using angular technologies. The code source is available 3   OrBAC takes into account the concept of hierarchy, which is the structural hierarchy. In the sense that it considers that an organisation can have sub-organisations (or that a network can have sub-networks for example). And that the rights one has in the macro organisation are superior to the rights of the sub organisation. But OrBAC does not model the functional hierarchy, it does not allow to implement the hierarchical control of activities in the information system.  Our model can be applied in two cases: authentication and authorization, unlike previous models that are only dedicated to authorization. One of the fundamental differences between our model and the previous models is based on the redundant authentication that we apply to secure access to resources. Indeed, these models rely totally on the proof of identity provided by the user to access the organization's resources, no matter who is acting behind this identity. And so a user once authenticated to the system can directly perform actions on the system resources, including critical actions. Although this is within the limit of his privileges, a malicious program (or person) can exploit these same permissions to act as the user and destroy the system. To achieve this we assume that there is a direct bijection between the organization's directory and the system's users. To perform critical actions the employee is authenticated a second time by his superiors within the organization.
In addition to this redundancy which reinforces the security of resources, our model respects the organization chart of companies, the notion of hierarchy is oriented by the functions of the company and the authorizations follow this same logic.
However, the involvement of hierarchical superiors (humans) in the access control process can cause saturation of access requests in the system when the system scales up. We addressed this issue in a previous article [27], by adding a new authentication layer based on the analysis of user habits in the system. And this new layer filters out the requests that finally need to be authenticated by the superiors. Furthermore our model can only work in an organisation with at least two employees (the super-user and the owner of the organization).

Conclusion
The aim of this article was to propose a formal description of the HOrBAC model. To do so, we first presented the concepts of this model through UML diagrams. Then we used the first order language to express the objects of the model and the relations between them. From this language we defined constants, variables and functions to specify a security policy based on HOr-BAC and proposed an example. This model excludes the notion of trusting employees by performing redundant authentication and can be an alternative to fight against impersonation, brute force and ransomware attacks that cause huge losses to companies. One of the current challenges is to reduce the response time to an access request between the different authentication layers. We have used the first order logic for its expressiveness, but this logic is semi-undecidable. Although some works have tried to propose decidable fragments [36,37], this language still remains abstract and does not take into account implementation details hence the need to complete this description with an implementation level language. Finally, the open source identity provider project based on this model lacks an integration part with client applications, we plan to complete this implementation in order to have a complete prototype.

Funding:
No funding was received for conducting this study.