# Secure Delegation Using Enhanced Capability Model

Authors: Kamran Habib Khan; Ikram Ud Din; Ahmad Almogren; Hasan Ali Khattak; Muhammad Ibrahim; Shah Nazir
Journal: Security and Communication Networks
 (2022)

---

## Abstract

A secure delegation has a key role in collaborative and dynamic systems, and it brings new challenges to security mechanisms. Secure delegation requires a flexible model that eliminates the challenges of access control and usage control services and provides separation of duty for static and dynamic circumstances. In this study, we propose a security service model that provides delegation of rights by restricting the delegation of sensitive permission as well as restriction from unauthorized access to resources. It also ensures that the delegation process hides information and privacy from competitors in an effective manner. The proposed model removes the administrative burden and establishes an automated delegation system. In addition, the model focuses on privacy and divides the duties with the fewest possible procedures. Moreover, exercising the model’s effectiveness with various circumstances and types of delegates has also been demonstrated.


---

## Body

## 1. Introduction

Delegation of rights is important for effectively providing security procedures. Several delegation procedures have been proposed for secure delegation, in which one of the most important procedures is the role-based access control model [1]. Role-based access control (RBAC) limits access to the network depending on the position of an individual within an organization. Delegation can come in a variety of contexts, including role reinforcement, work coordination, and control decentralization. If a person is out of reach or is absent for an extended period, his/her job functions must be delegated to another individual and managed by others. When people need to work with others in the same or other organizations, they must be granted some level of access authorization to share information. Finally, work functions are allocated from higher to lower job positions when an organization chose to establish up initially or reorganize afterward.The RBAC functions apply to the degree of access employees have to the network [2]. Several delegation models have been developed but it has been questioned which model suits a specific situation. We discuss some of these cases in Section 5. We propose a “Secure Delegation with Enhanced Capability Model” that is driven by Static and Dynamic Separation of Duty (SSOD, DSOD) policies in the same and cross-domain to handle complexities that have not been covered by the existing models. Unlike other models that are explained in Section 2, the proposed model eliminates the administration overhead by automating the processes and enhancing the control to delegate over roles, permissions, and capability. Secure delegation requires an access control management system, where organizations store and record their confidential data. The proposed system makes better use of policies for storing information and preserving the security and privacy of resources.Secure delegation in a cross-domain requires a stout access control management system, where organizations interoperate and utilize resources such as confidential data. The proposed framework makes use of predefined protocols that include a broad variety of access control procedures for knowledge management and resource sharing. The proposed model takes into account the aforementioned operations to be a realizable and supportable exterior to the current domain.The rest of the study is organized as follows: Section2 includes the details on access control mechanisms and delegation models relevant to the problem statement, which is discussed in Section 3. Related works and the issues addressed are explained in Section 4. A motivational example is explained in Section 5. The methodology adopted to address the research objectives is presented in Section 6.


## 2. Background

An access control policy aims at setting security requirements and ensuring controlled access to the information resources. Access to information is regulated based on business and security requirements and access control rules for each information system are established. A trusted computing base is everything in the system that provides security and privacy for a given environment. A network trusted computing base is the environment in the network that is responsible for the security of hardware, software, and firmware and the implementation of their policies. The first step in the development of an access control system is the identification of objects and subjects that execute activities on objects. Subjects, objects, and actions are different for different systems. Bell and Lapadula developed the access model that focuses on data confidentiality and falls in line with the classification of information [2, 3]. The access control policy in this model consists of a division of entities into subjects and objects. Objects in access control policy refer to security classification and subjects are referred to as security clearance. The system state is said to be secured if access modes of subjects to objects lie within the security policy [4]. The Biba model was introduced by K. J. Biba in 1977 and was the first security model in the field of integrity; it is also a lattice-based access control security model that deals with sensitive information at various levels. The key concept is to implement the information management approach using compulsory control of access to improve discretionary control of access. Every subject and object in the Biba model have its degree of integrity. The higher data level is more accurate and reliable than the lower [5]. The Biba model works on the principle of maintaining the integrity of information, and it prevents subjects that modify information indirectly that they cannot change. The main idea of the Biba model is present in the structure of security classes such that every class has some standards of credibility so that the highest credibility classes are at the peak and the lowest credibility classes are at the very end of the structure. Information was permitted to migrate from a high degree of integrity to a low degree of integrity [6]. The theme of access control governs the access capacity of objects using permission policies. Its purpose is to protect legal users from unlawful use of system resources and to prevent unauthorized use of system resources by unauthorized users. Access control lists are semantics used for granting access permissions and access control services to monitor which access is granted to resources. The access matrix model that was developed by Harrison, Ruzzo, and Ullman works based on three logics: subjects, objects, and resources. Access control list (ACL) is a set of rules for access permissions that are given to users, groups, or system objects such as processes, programs, and objects. Using these semantics, we can reduce the conflicts of similar permissions that have different semantics. If we have several resource levels, then for every level, making these types of semantics may be challenging and create hurdles; Gladney proposes the solution of combining subjects and objects within an equivalent version so this can decrease the size of ACL [7]. We introduce the “Separation of Duty” principle in the proposed model so that the delegation process is now more secure. The main theme of the model is the mapping of the transferable units to permissions and roles so they can be transferred. It is important to provide a mechanism that transfers permission and roles of the host domain to the requester when there is an independent hierarchy of roles in multiple domains. This can be achieved using the constraint-based role-based access control (CRBAC) model [8].


## 3. Problem Statement

Resource sharing among multidomains requires authorization to access data, services, and applications. Two roles are mutually exclusive if no single user allows being the member of both roles, which are referred to as statically mutual exclusive constraints. The constraints may be obligate if no single user activates two or more roles that are mutually exclusive at a single time in any session, which are known as dynamically mutually exclusive roles. To avoid this challenge separation of duty principle, sensitive tasks are prevented from being performed by single users only. Multidomain policy supervision and interoperation among different systems may create conflicts because different domains have their models, access control policies, semantics, and labeling policies. We propose the model for the cross-domain delegation, which deals with the separation of duty principle effectively. The unit of delegation for our model is the enhanced ability unit (EAU). Static separation of duty and dynamic separation of duty provide access to permissions to the least number of users that perform given tasks. Therefore, static mutual exclusive role (SMER) or dynamic mutual exclusive role (DMER) are the methods for attaining static separation of duty or dynamic separation of duty policies.


## 4. Related Work

Different delegation models have been developed and comparison states the characteristics of different delegation approaches. The famous RBAC approach presents the concept of role and assigns roles to users, making the authorization process easier to handle. RBAC is offered by most cloud service providers, in which participants are clustered into roles and access is granted to role-based services [9]. The break glass approach is used for uninterrupted systems like hospitals [10]. The purpose-oriented situation-aware access control provides access control according to the situation [11]. The automatic access control distributes access privileges to subjects, which is a concern. The authorization is associated with roles initially, and afterward, the role of users is established in the RBAC model. The authorization of users is achieved via user roles, and resources (objects) are handled [12]. The role-based access control (RBAC) is a method for defining and evaluating security access to various system artifacts, including data, functions, and services.A user is described as a person, although this term could be expanded to include autonomous machines, networks, and intelligent agents. Within an organization, a role is a job function. The authority and duty bestowed on the function entrusted to the user are two semantics that are connected. A session is a mapping between a user and an activated subset of roles to which the user is assigned. A permit is an authorization to work on one or more protected objects. An operation is an executable image of a program that performs some function for the user upon invocation [13]. Discretionary access control is a type of access control strategy that restricts subject access based on their identity and linked groups. Subjects with access privileges can transfer such rights to other subjects via DAC. Attribute-based encryption helps as a beneficial cryptographic tool to safely exchange data in a refined fashion with valid recipients [14]. The DAC concept makes it simple for consumers to change their access strategy. Access control for automated vehicles (AC4AV) provides APIs for run time adjustments of access control models for vehicles and the same can be done for other machine-to-machine communication in the industry [15, 16].To handle access control issues in blockchain, the token-constrained permission delegation algorithm is used, which transforms the access control policy corresponding to permissions into authorization usage restrictions, implements the permission token constraints, and forms limitations on the transfer of tokens [17]. Attribute-based access control (ABAC) is a generic cross-domain authorization technique for different forms of access control models [18], which also fits in service-oriented architecture (SOA) [19]. Mandatory access control (MAC) is a system-enforced access control, based on the clearance of a subject and the labeling of an object. Subjects and objects have clearances and labels as confidential, secret, and top secret, respectively.A subject can only enter an object if the clearance of the subject is equal to or greater than that of the mark of the object. Subjects cannot exchange items with other subjects who neither have the necessary clearance, nor can they “write down” things to a lower categorization level (such as from top secret to secret). The primary goal of MAC systems is to protect data secrecy. Three basic elements (subject, object, and permission) and three process elements make up the usage control model (authorized rules, conditions, and obligations) that encapsulates the requirements and obligations that the subject must meet during the model authorization process. This model not only includes four common access control models, such as MAC mode, DAC mode, RBAC mode, and ABAC mode, but also digital rights management and trust management material [12]. With only a rudimentary grasp of how to apply process mining for RBAC analysis, a systematic literature review (SLR) was conducted to remedy the gap, with the goal of determining the major features of existing techniques to process mining for RBAC analysis [20]. The context-aware access control model provides the secure accessing of information and resources using the features of the role-based access control model. It consists of context-aware user-role assignments and context-aware role-permission assignments. The Context-aware access control model used a dynamic association of user-role and role-service capabilities [21]. However, the solution may be doubtful because this may lead to the leakage of information as there is no mechanism for the restriction of sensitive information in the transfer unit. Also, the separation of duty is not counted, hence information may be leaked without the permission of the resource manager. A lot of work has been done in the field of security and delegation by providing a more fine-grained and safe process of empowering access to resources. However, a more sophisticated mechanism is needed for improving delegation and influencing the delegation mechanism. Therefore, we are confident enough that the proposed approach will improve delegation and influence the delegation mechanism.


## 5. Motivating Example

In a bank, two employees hire consultancy services from a consultancy firm. Both of the employees are of the same rank. It is obvious that none of the employees want their privacy and confidential data to be disclosed to each other for the benefit of promotions and advancements in their careers. Thus the consultant’s operations on data, facts, statistics, results, and suggestions must be amorphous. The hiring of the same consultant by both parties for consultancy in this situation could lead to the leakage of private and sensitive information. We tackle the issue by EAU, which makes sure that the same consultant (check made based on IDs when delegating EAU) cannot be appointed to more than one employee of the same rank irrespective of the time or date of assignment. The EAU mechanism also eliminates manual administrative operation and its consequent charges by automating the process of authorization access. Similar is the case of hiring marketing advisors by two or more competitor companies. This could create a possibility of leakage and the flow of confidential information between competitors. The EAU makes corresponding authorizations and allows access to delegatee only if the delegatee has not provided services to the same company type. Another possibility is in a scenario where a patient’s entire medical history is maintained by his/her family doctor and the patient, and due to an emergency, he/she is taken to a nearby hospital, where he/she is examined by some other doctors. The doctor needs delegated access to the patient’s medical history to provide necessary treatment. However, the family doctor intends to make sure that the access to data is read-only and that the access right is nontransferable to any other doctor or nurse due to privacy and modification issues. The EAU imposes such constraints by differentiating and further limiting transferable and limit-transferable permissions (provided constraints such as lifetime and number of hops). The sensitive permissions can only be transferred in a special case with a limited lifespan and the hop count, provided the SOD restrictions are checked before access is granted.


## 6. Proposed Solution

The EAU acquaints static and dynamic mutual exclusive roles enforcement for both same and cross-domain delegations. We also introduce sensitive roles and sensitive permissions (also known as limit transferable) within the EAU to allow the transfer of delegation to only authorized entities even after the EAU is transferred to the delegatee, thus protecting rights and privileges as conveyed by the main authority of resources even after transferring the delegation. We use the following basic assignments related to the present solution:(i)
URA⊆UχR,UχR used for user-role mapping.(ii)
UPA⊆UχP,UχP used for user-permission mapping.(iii)
USA⊆UχS,UχS used for user-particular session mapping.(iv)
RPA⊆RχP,RχP used for role-permission assignment relation.(v)
UCA⊆UχC,UχC used for user-capability assignment relation.(vi)
CRA⊆CχR,CχR used for capability’s function-role’s assignment relation.(vii)
CPA⊆CχP,CχP used for capability’s function-permission’s function assignment relation.


## 7. Constraints on Capability

For sustainable and predictable capability delegations among individuals and multidomains, we identify certain capability entity constraints. Such constraints refer to a capability validity period, several activations, and the time required for the development of capability. The delegator defines these constraints during the creation of capability and is imposed after the activation of capability by the delegate.We have listed capability/cap-z as c and capability/cap-z\}: acute: over ¡/i¿ as c\}: acute: over ¡/i¿ for simplifying the structure in formal work.lif _ tim(c) < ses(c) ∈ Sessionselse lif _ tim(c) ≥ ses (c) ∉ SessionsThe given constraint presents a capability’s potential duration as opposed to a given capability’s session time. A capability’s lifespan comes to a finishing point when the session expires.limt _ act(c) ≤ limt _ cap ∈ act _ capelse limt _ act(c) > limt _ cap ∉ act _ capThis constraint puts a limit over the number of times a delegate can activate a capability.limt _ cre(c) ≤ limt _ cap ∈ cre _ capelse limt _ cre(c) > limt _ cap ∉ cre _ capThe mentioned constraint puts a limit on the possibility of creating capability by the delegate.limt _ hop(c) ≤ limt _ cap ∈ hop _ capelse limt _ hop> limt _ cap ∉ hop _ capThis constraint presents the total number of hops any capability can achieve.


### 7.1. Case Study 1

In this study, let us recognize a bank and call it Bank-X for better understanding. Bank-X has several employees with various roles and responsibilities, specific ranks, and activities to do with variance. Banks are known as sensitive entities needing a high degree of protection and privacy. Also within a bank, multiple functions and permissions operate safely, only if they are distributed among a particular number of users. Assuming that any 5 permissions/roles need to be dispersed among any 3 users of a particular bank for the safe execution of tasks, the moment 2 users get empowered to perform these 5 permissions/roles, and the scenario leads to harmful results for the bank in terms of privacy and security. All roles that may trigger detrimental effects are known as mutual exclusive roles if performed by a single user or by any number of users less than the desired. The policy elucidated for such kinds of cases is known as separation of duty (SOD) in literature. That is subdivided into static separation of duty (SSOD) and dynamic separation of duty (DSOD). For the presented scenario policy, the SSOD can be written as follows:(1)SSOD=r1,r2,r3,r4,r5,3.This policy defined thatr1, r2, r3, r4, r5 need to register for at least 3 users for the safe and secure functioning of the system. The moment any two or fewer users govern to exercise the 5 roles, that leads to sabotaging the safety of the organization. The constraints used for enforcement of the SSOD and DSOD are called static mutually exclusive role (SMER) and dynamic mutually exclusive role (DMER) respectively. The use of the constraint to apply such SOD policy can be described as follows:(2)DMER=r1,r2,r3,r4,r5,4.The given constraint stated that no user is empowered enough for the execution of 4 roles at a given time. It also states that a single user can only exercise 3 roles from the given set and the remaining roles need to be executed by the rest of the users. This implies that only one of the users can exercise three roles, while the other two roles are exercised by the rest of the members:(3)SOD=r1,r2,r3,r4,r5,4,3.Suppose a bank has multiple workers employed at several ranks. Let us assume that Bank-X has two staff members, both of whom work in the same department. Bank-X seeks to implement a loan program, for which Bank’s one employee known as BxEmp-A and another employee known as BxEmp-B need consultancy to assess and receive professional guidance on several official issues. At the moment, they also need data privacy and decision privacy among the rest of the employees working in the exact bank. BxEmp-A has assigned the job of searching for loan applicants and BxEmp-B has assigned the role of verifying applicants and approval of loans. The task is divided among multiple employees for the minimization of fraud. BxEmp-A gathered a list of some reputed companies and for a profound opinion, hired a consultant to grade the companies. In the meantime, BxEmp-B drew some sentiments about the provided companies and also needed an expert opinion analyst on the findings. If both employees select the same consultant, there is a bright chance of committing perjury. That does say that BxEmp-A does not desire to unfold his/her data to BxEmp-B, and BxEmp-B holds the same intentions. They do not want their private data to be exchanged and want to ensure that their actions, documents, facts, and statistics were not disclosed. The concept can be raised from SOD’s basic aspect.In Figure1 the Bank-X initiated a new program, and the project needs consultancy services for evaluation and some suggestions over official matters. This charge of dealing with the situation is handed over to BxEmp-A. BxEmp-A as an in charge of the new program, broadcast advertising for business consulting at Bank-X. A consultant dyCon-A from consultancy services responds to BxEmp-A and shows his/her willingness for providing services of consultancy. BxEmp-A initiated a cap-z that consists of the roles and permissions necessary for advisory and constraints such as(i)
Lifetime(ii)
Number of activation(iii)
Capability creation count(iv)
Hop count of transfer of a capability(v)
SOD checkare elucidated over the cap-z, in a manner that secures and controls the rights according to the creator’s choice. BxEmp-A then assigns cap-z to dyCon-A within a cross-scope.Conditions for SSOD are as follows:BxEmp-A:=r1 and BxEmp-B :=r2 while SMER= r1,r2,2BxEmp-Ar1 dyCon-A ˄ BxEmp-B r2 dyCon-AWhen approached by our solution, this condition deliversBxEmp-Ar1 dyCon-A ˄ BxEmp-B r2 dyCon-BAs SMER =r1,r2,2The advantage of following this model is that the dyCon-A delegation construct cannot enter Bank-X until dyCon-A meets the SOD test criteria. In addition, SOD test guarantees that dyCon-A has no further function that represents mutual exclusion to cap-z roles/permissions. The whole process can be achieved without the help of an administrator in an automatic manner. The cap-z possesses high smartness; it has the power to distinguish some shared exclusive roles/permissions on its own. The cap-z is fully assigned to dyCon-A and since dyCon-A has no mutually exclusive role/permission, dyCon-A accesses Bank-X database by exercising the roles/permissions received in the cap-z. In the presented model, the constraints on roles and permissions are introduced on the capability level as well, which is elaborated in the next test case. dyCon-A has accessed the required data and writes the changes back to the database of Bank-X and dyCon-A status is updated by BxEmp-A. Basically, the status update consists of mentioning the roles and responsibilities used by dyCon-A during consultancy service. The result of checking dyCon-A status helps SOD to place a check on capability work. This status update eliminates administration tasks and automates the processes entirely.In the same manner, the Bank-X employee BxEmp-B requires project consultancy and upon the consultancy advertisement, receives a reply from the same consulting company and the same consultant, identified as dyCon-A. BxEmp-B originates the capability we refer to as cap-z, which retains the same roles/permissions and enforces the same restrictions on its lifetime, the number of new capabilities produced, the number of activation, and the number of power transfer hops. BxEmp-B assigned the cap-z to dyCon-A in a cross-domain. Now the cap-z is of no use until the SOD check is satisfied, but dyCon-A already provided consultancy to BxEmp-A and as we are aware that BxEmp-A and BxEmp-B have mutually exclusive roles as follows:BxEmp-A:=r1 and BxEmp-B :=r2 while SMER= r1,r2,2Because of the constraint enforcement, even after cap-z is provided, dyCon-A cannot enable the cap-z. BxEmp-B provides a negative comment on dyCon-A having certain exclusive roles/permissions with each other. Soon after that, BxEmp-B is looking forward to seeing another consultant from the same or separate company. With other consultants, the same protocol is followed as well, just as no individual can exercise either of the roles that are considered to be mutually exclusive. This holds the value of Bank-X and its credibility.Delegation function is as follows:(4)SSOD=r1,r2,2.The SSOD policy represents that “n” number of roles needs to be exercised by a minimum “k” number of users:cap-z:=r1 where Bank-X posses the role r1D1:S⟶cre (BxEmp-A, c1, dyCon)and as previously describedc = cap-zwhere cap-z:=r1S⟶asg (dyCon-A, c1) where dy is domain of consultantS⟶tran (BxEmp-A, dyCon-A, c1)S⟶act (dyCon-A, c1, SMER)dyCon-Ac1where SMER =r1,r2,2D2:S⟶cre (BxEmp-B, c2, dyCon)cap-z:=r2S⟶asg (dyCon-A, c2)S⟶tran (BxEmp-B, dyCon-A, c2)S⟶act (dyCon-A, c2, SMER)dyCon-A⟶∼actc2asr1 and r2 are mutually exclusiveS⟶asg (dyCon-B, c2)S⟶tran (BxEmp-B, dyCon-B, c2)S⟶act (dyCon-B, c2, SMER)dyCon-B⟶actc2BxEmp-A initiates a capabilityc1 for dyCon. c1 possesses r1 and c1 is conveyed to dyCon-A, where Con refers to a consultant and dy represents the domain of the consultant. The SSOD check is situated until dyCon-A begins triggering the c1 functionality. The same procedure takes place for BxEmp-B. BxEmp-B initiates capability c2 having r2 and is assigned to dyCon-A but fails to trigger c2, as in this particular situation, the regulation check does not satisfy. After the failure of policy verification, BxEmp-B assigns c2 to dyCon-B. dyCon-B triggers c2, since dyCon-B has no mutual exclusive role.


### 7.2. Case Study 2

Now, we are concerned with numerous cross-domain delegations. Bridgestone and Dunlop are recognized corporations for this study. To make things simple, we call them BS and DL respectively. Both corporations possess the amount of staff in several ranks. Let us consider an employee BSEmp-A from Bridgestone who is responsible for advertising specific activities, such as making plans for a marketing advisor to delegate an appropriate collection of roles/permission for consulting matters to the marketing advisor. Similarly, an employee DLEmp-A from Dunlop is assigned with similar engagements regarding consultancies. Corporations offer schemes and other allowances for their employees to achieve the integrity of their data. They are curious about protecting rivals’ internal practices and confidential information. Both BSEmp-A and DLEmp-A hold the same ranks at their respective organizations and need marketing advisors from a trustworthy consultancy company as shown in Figure2. Marketing consultants from various marketing companies illustrate their willingness to provide services. Marketing firms do not possess much knowledge about clients and their rivals. They have no strategy for maintaining lists of rivals in the industry. It also means that after a marketing advisor has worked with Bridgestone, the individual marketing advisor is not supposed to offer consulting services with Dunlop during the defined amount of time provided by Bridgestone, as none of the competitors plan to reveal their information to anyone. Given the time factor involved, this case falls within the dynamic separation of duty (DSOD) framework, and DMER constraint is required to implement DSOD.Figure 1
SSOD in cross-domain.Figure 2
DSOD in cross-domain.BSEmp-A broadcast advertisements for consultancy services for their new product launch, and is in a need of skillful opinion and likes to have market research on the subject. The marketing advisor responded to the ad from Roland Berger, recognized as RB-A, and expressed interest in offering his/her services as a consultant. BSEmp-A generates the cap-z and imposes the required constraints such as limitations on activation number, lifetime, limitation on the number of new capabilities generation, SOD check over the capability, and constraints over the number of hops a capability can transfer. Further cap-z is transferred by BSEmp-A and received by RB-A, respectively. Afterward, the automated process of SOD takes into account the mutually exclusive roles/permissions and made sure that RB-A is qualified for cap-z. RB-A enables the cap-z to pursue the Bridgestone database on the root roles/permissions obtained from BSEmp-A. RB-A is authorized to collect, write, or read data from the Bridgestone database, depending on the roles/permissions received. BSEmp-A changed RB-A status after consultation and before the issuance of payment voucher. The status report provides a list of the RB-A roles/permissions performed and is known to better protect the reputation of Bridgestone as any other competitor company decides to employ the same consultancy services.Conditions for DSOD are as follows:BSEmp-A:=r1 and DLEmp-A :=r2 while DMER = r1,r2,2BSEmp-Ar1 RB-A ˄ DLEmp-A r2 RB-AWe deal with this situation using the presented approach asBSEmp-Ar1 RB-A ˄ DLEmp-A r2 RB-BAs DMER =r1,r2,2As a company, Dunlop wants a certain marketing strategy and DLEmp-A has broadcast an advertisement to employ a consultant on certain issues. RB-A, an employee of Roland Berger marketing company replied to the advertisement, and DLEmp-A obtained an acknowledgment of RB-A willingness to provide consultancy services. DLEmp-A generated the cap-z and added the necessary limitations and a SOD check. The cap-z is transferred to RB-A, and the specified automation method tests with RB-A for the mutual exclusive roles/permissions. In this particular case, the notification of mutually exclusive roles/permissions pops up, as RB-A has interacted with BSEmp-A before. Because of that RB-A cannot activate the cap-z, DLEmp-A is forwarded to his/her co-marketing consultant in the same company, so DLEmp-A has the option of selecting another marketing consultant from the same company or a different one. In this case, DLEmp-A chooses the RB-B co-marketing advisor, transfers the capability to RB-B, and after searching for shared exclusive roles/permissions RB-B, successfully activates the capability and begins to exercise the Dunlop’s database based on delegated privileges.The delegation function is as follows:(5)DSOD=r1,r2,2.The DSOD policy indicates that at a given time, at least “k” number of users entertain the “n” number of roles:cap-z:=r1 where r1 is the role of BSD1:S⟶cre (BSEmp-A, c1, RB-A)and as previously describedc = cap-zwhere cap-z:=r1S⟶asg (RB-A, c1)S⟶tran (BSEmp-A, RB-A, c1)S⟶act (RB-A, c1, DMER)RB-A⟶actc1where DMER =r1,r2,2D2:S⟶cre (DLEmp-A, c2, RB-A)cap-z:=r2S⟶asg (RB-A, c2)S⟶tran (DLEmp-A, RB-A, c2)S⟶act (RB-A, c2, DMER)RB-A⟶actc2asr1 and r2 are dynamically mutually exclusive.S⟶asg (RB-B, c2)S⟶tran (DLEmp-A, RB-B, c2)S⟶act (RB-B, c2, DMER)RB-B⟶actc2BSEmp-A initiates a capabilityc1 for marketing advisor RB-A. c1 includes r1 and granted to RB-A. SSOD checks are put until RB-A can enable the c1 functionality. The same cycle is repeated for DLEmp-A. DLEmp-A generates c2 capabilities that have r2. c2 is passed to RB-A, but RB-A does not trigger c2 since, in this situation, the protocol check is not satisfied. Following failure of the policy verification, DLEmp-A delegates c2 to RB-B. dyCon-B triggers c2, since RB-B has no mutual exclusive function.


## 7.1. Case Study 1

In this study, let us recognize a bank and call it Bank-X for better understanding. Bank-X has several employees with various roles and responsibilities, specific ranks, and activities to do with variance. Banks are known as sensitive entities needing a high degree of protection and privacy. Also within a bank, multiple functions and permissions operate safely, only if they are distributed among a particular number of users. Assuming that any 5 permissions/roles need to be dispersed among any 3 users of a particular bank for the safe execution of tasks, the moment 2 users get empowered to perform these 5 permissions/roles, and the scenario leads to harmful results for the bank in terms of privacy and security. All roles that may trigger detrimental effects are known as mutual exclusive roles if performed by a single user or by any number of users less than the desired. The policy elucidated for such kinds of cases is known as separation of duty (SOD) in literature. That is subdivided into static separation of duty (SSOD) and dynamic separation of duty (DSOD). For the presented scenario policy, the SSOD can be written as follows:(1)SSOD=r1,r2,r3,r4,r5,3.This policy defined thatr1, r2, r3, r4, r5 need to register for at least 3 users for the safe and secure functioning of the system. The moment any two or fewer users govern to exercise the 5 roles, that leads to sabotaging the safety of the organization. The constraints used for enforcement of the SSOD and DSOD are called static mutually exclusive role (SMER) and dynamic mutually exclusive role (DMER) respectively. The use of the constraint to apply such SOD policy can be described as follows:(2)DMER=r1,r2,r3,r4,r5,4.The given constraint stated that no user is empowered enough for the execution of 4 roles at a given time. It also states that a single user can only exercise 3 roles from the given set and the remaining roles need to be executed by the rest of the users. This implies that only one of the users can exercise three roles, while the other two roles are exercised by the rest of the members:(3)SOD=r1,r2,r3,r4,r5,4,3.Suppose a bank has multiple workers employed at several ranks. Let us assume that Bank-X has two staff members, both of whom work in the same department. Bank-X seeks to implement a loan program, for which Bank’s one employee known as BxEmp-A and another employee known as BxEmp-B need consultancy to assess and receive professional guidance on several official issues. At the moment, they also need data privacy and decision privacy among the rest of the employees working in the exact bank. BxEmp-A has assigned the job of searching for loan applicants and BxEmp-B has assigned the role of verifying applicants and approval of loans. The task is divided among multiple employees for the minimization of fraud. BxEmp-A gathered a list of some reputed companies and for a profound opinion, hired a consultant to grade the companies. In the meantime, BxEmp-B drew some sentiments about the provided companies and also needed an expert opinion analyst on the findings. If both employees select the same consultant, there is a bright chance of committing perjury. That does say that BxEmp-A does not desire to unfold his/her data to BxEmp-B, and BxEmp-B holds the same intentions. They do not want their private data to be exchanged and want to ensure that their actions, documents, facts, and statistics were not disclosed. The concept can be raised from SOD’s basic aspect.In Figure1 the Bank-X initiated a new program, and the project needs consultancy services for evaluation and some suggestions over official matters. This charge of dealing with the situation is handed over to BxEmp-A. BxEmp-A as an in charge of the new program, broadcast advertising for business consulting at Bank-X. A consultant dyCon-A from consultancy services responds to BxEmp-A and shows his/her willingness for providing services of consultancy. BxEmp-A initiated a cap-z that consists of the roles and permissions necessary for advisory and constraints such as(i)
Lifetime(ii)
Number of activation(iii)
Capability creation count(iv)
Hop count of transfer of a capability(v)
SOD checkare elucidated over the cap-z, in a manner that secures and controls the rights according to the creator’s choice. BxEmp-A then assigns cap-z to dyCon-A within a cross-scope.Conditions for SSOD are as follows:BxEmp-A:=r1 and BxEmp-B :=r2 while SMER= r1,r2,2BxEmp-Ar1 dyCon-A ˄ BxEmp-B r2 dyCon-AWhen approached by our solution, this condition deliversBxEmp-Ar1 dyCon-A ˄ BxEmp-B r2 dyCon-BAs SMER =r1,r2,2The advantage of following this model is that the dyCon-A delegation construct cannot enter Bank-X until dyCon-A meets the SOD test criteria. In addition, SOD test guarantees that dyCon-A has no further function that represents mutual exclusion to cap-z roles/permissions. The whole process can be achieved without the help of an administrator in an automatic manner. The cap-z possesses high smartness; it has the power to distinguish some shared exclusive roles/permissions on its own. The cap-z is fully assigned to dyCon-A and since dyCon-A has no mutually exclusive role/permission, dyCon-A accesses Bank-X database by exercising the roles/permissions received in the cap-z. In the presented model, the constraints on roles and permissions are introduced on the capability level as well, which is elaborated in the next test case. dyCon-A has accessed the required data and writes the changes back to the database of Bank-X and dyCon-A status is updated by BxEmp-A. Basically, the status update consists of mentioning the roles and responsibilities used by dyCon-A during consultancy service. The result of checking dyCon-A status helps SOD to place a check on capability work. This status update eliminates administration tasks and automates the processes entirely.In the same manner, the Bank-X employee BxEmp-B requires project consultancy and upon the consultancy advertisement, receives a reply from the same consulting company and the same consultant, identified as dyCon-A. BxEmp-B originates the capability we refer to as cap-z, which retains the same roles/permissions and enforces the same restrictions on its lifetime, the number of new capabilities produced, the number of activation, and the number of power transfer hops. BxEmp-B assigned the cap-z to dyCon-A in a cross-domain. Now the cap-z is of no use until the SOD check is satisfied, but dyCon-A already provided consultancy to BxEmp-A and as we are aware that BxEmp-A and BxEmp-B have mutually exclusive roles as follows:BxEmp-A:=r1 and BxEmp-B :=r2 while SMER= r1,r2,2Because of the constraint enforcement, even after cap-z is provided, dyCon-A cannot enable the cap-z. BxEmp-B provides a negative comment on dyCon-A having certain exclusive roles/permissions with each other. Soon after that, BxEmp-B is looking forward to seeing another consultant from the same or separate company. With other consultants, the same protocol is followed as well, just as no individual can exercise either of the roles that are considered to be mutually exclusive. This holds the value of Bank-X and its credibility.Delegation function is as follows:(4)SSOD=r1,r2,2.The SSOD policy represents that “n” number of roles needs to be exercised by a minimum “k” number of users:cap-z:=r1 where Bank-X posses the role r1D1:S⟶cre (BxEmp-A, c1, dyCon)and as previously describedc = cap-zwhere cap-z:=r1S⟶asg (dyCon-A, c1) where dy is domain of consultantS⟶tran (BxEmp-A, dyCon-A, c1)S⟶act (dyCon-A, c1, SMER)dyCon-Ac1where SMER =r1,r2,2D2:S⟶cre (BxEmp-B, c2, dyCon)cap-z:=r2S⟶asg (dyCon-A, c2)S⟶tran (BxEmp-B, dyCon-A, c2)S⟶act (dyCon-A, c2, SMER)dyCon-A⟶∼actc2asr1 and r2 are mutually exclusiveS⟶asg (dyCon-B, c2)S⟶tran (BxEmp-B, dyCon-B, c2)S⟶act (dyCon-B, c2, SMER)dyCon-B⟶actc2BxEmp-A initiates a capabilityc1 for dyCon. c1 possesses r1 and c1 is conveyed to dyCon-A, where Con refers to a consultant and dy represents the domain of the consultant. The SSOD check is situated until dyCon-A begins triggering the c1 functionality. The same procedure takes place for BxEmp-B. BxEmp-B initiates capability c2 having r2 and is assigned to dyCon-A but fails to trigger c2, as in this particular situation, the regulation check does not satisfy. After the failure of policy verification, BxEmp-B assigns c2 to dyCon-B. dyCon-B triggers c2, since dyCon-B has no mutual exclusive role.


## 7.2. Case Study 2

Now, we are concerned with numerous cross-domain delegations. Bridgestone and Dunlop are recognized corporations for this study. To make things simple, we call them BS and DL respectively. Both corporations possess the amount of staff in several ranks. Let us consider an employee BSEmp-A from Bridgestone who is responsible for advertising specific activities, such as making plans for a marketing advisor to delegate an appropriate collection of roles/permission for consulting matters to the marketing advisor. Similarly, an employee DLEmp-A from Dunlop is assigned with similar engagements regarding consultancies. Corporations offer schemes and other allowances for their employees to achieve the integrity of their data. They are curious about protecting rivals’ internal practices and confidential information. Both BSEmp-A and DLEmp-A hold the same ranks at their respective organizations and need marketing advisors from a trustworthy consultancy company as shown in Figure2. Marketing consultants from various marketing companies illustrate their willingness to provide services. Marketing firms do not possess much knowledge about clients and their rivals. They have no strategy for maintaining lists of rivals in the industry. It also means that after a marketing advisor has worked with Bridgestone, the individual marketing advisor is not supposed to offer consulting services with Dunlop during the defined amount of time provided by Bridgestone, as none of the competitors plan to reveal their information to anyone. Given the time factor involved, this case falls within the dynamic separation of duty (DSOD) framework, and DMER constraint is required to implement DSOD.Figure 1
SSOD in cross-domain.Figure 2
DSOD in cross-domain.BSEmp-A broadcast advertisements for consultancy services for their new product launch, and is in a need of skillful opinion and likes to have market research on the subject. The marketing advisor responded to the ad from Roland Berger, recognized as RB-A, and expressed interest in offering his/her services as a consultant. BSEmp-A generates the cap-z and imposes the required constraints such as limitations on activation number, lifetime, limitation on the number of new capabilities generation, SOD check over the capability, and constraints over the number of hops a capability can transfer. Further cap-z is transferred by BSEmp-A and received by RB-A, respectively. Afterward, the automated process of SOD takes into account the mutually exclusive roles/permissions and made sure that RB-A is qualified for cap-z. RB-A enables the cap-z to pursue the Bridgestone database on the root roles/permissions obtained from BSEmp-A. RB-A is authorized to collect, write, or read data from the Bridgestone database, depending on the roles/permissions received. BSEmp-A changed RB-A status after consultation and before the issuance of payment voucher. The status report provides a list of the RB-A roles/permissions performed and is known to better protect the reputation of Bridgestone as any other competitor company decides to employ the same consultancy services.Conditions for DSOD are as follows:BSEmp-A:=r1 and DLEmp-A :=r2 while DMER = r1,r2,2BSEmp-Ar1 RB-A ˄ DLEmp-A r2 RB-AWe deal with this situation using the presented approach asBSEmp-Ar1 RB-A ˄ DLEmp-A r2 RB-BAs DMER =r1,r2,2As a company, Dunlop wants a certain marketing strategy and DLEmp-A has broadcast an advertisement to employ a consultant on certain issues. RB-A, an employee of Roland Berger marketing company replied to the advertisement, and DLEmp-A obtained an acknowledgment of RB-A willingness to provide consultancy services. DLEmp-A generated the cap-z and added the necessary limitations and a SOD check. The cap-z is transferred to RB-A, and the specified automation method tests with RB-A for the mutual exclusive roles/permissions. In this particular case, the notification of mutually exclusive roles/permissions pops up, as RB-A has interacted with BSEmp-A before. Because of that RB-A cannot activate the cap-z, DLEmp-A is forwarded to his/her co-marketing consultant in the same company, so DLEmp-A has the option of selecting another marketing consultant from the same company or a different one. In this case, DLEmp-A chooses the RB-B co-marketing advisor, transfers the capability to RB-B, and after searching for shared exclusive roles/permissions RB-B, successfully activates the capability and begins to exercise the Dunlop’s database based on delegated privileges.The delegation function is as follows:(5)DSOD=r1,r2,2.The DSOD policy indicates that at a given time, at least “k” number of users entertain the “n” number of roles:cap-z:=r1 where r1 is the role of BSD1:S⟶cre (BSEmp-A, c1, RB-A)and as previously describedc = cap-zwhere cap-z:=r1S⟶asg (RB-A, c1)S⟶tran (BSEmp-A, RB-A, c1)S⟶act (RB-A, c1, DMER)RB-A⟶actc1where DMER =r1,r2,2D2:S⟶cre (DLEmp-A, c2, RB-A)cap-z:=r2S⟶asg (RB-A, c2)S⟶tran (DLEmp-A, RB-A, c2)S⟶act (RB-A, c2, DMER)RB-A⟶actc2asr1 and r2 are dynamically mutually exclusive.S⟶asg (RB-B, c2)S⟶tran (DLEmp-A, RB-B, c2)S⟶act (RB-B, c2, DMER)RB-B⟶actc2BSEmp-A initiates a capabilityc1 for marketing advisor RB-A. c1 includes r1 and granted to RB-A. SSOD checks are put until RB-A can enable the c1 functionality. The same cycle is repeated for DLEmp-A. DLEmp-A generates c2 capabilities that have r2. c2 is passed to RB-A, but RB-A does not trigger c2 since, in this situation, the protocol check is not satisfied. Following failure of the policy verification, DLEmp-A delegates c2 to RB-B. dyCon-B triggers c2, since RB-B has no mutual exclusive function.


## 8. Verification Mechanism

A company XA needs to hire a consultant, so they request Company XB for providing them with a consultant:(i)
The provided consultant is not supposed to be working or worked for any of their competitors yet.(ii)
Company XB is obliged to provide a valid proof of record that the provided consultant is not working or worked for any of their competitors.Company XB provides company XA names and records of the consultant that better suit the requirements of company XA. Company XA has the right to ask for proof that the particular consultant is neither working nor worked for their competitor. As a proof that the particular consultant is neither working nor worked for their competitors, Company XB sends Company XA, a list of consultants working at the moment for company XB, where the sent list contains information about the consultant along with a file containing the hash information. Information regarding other consultants in the file is all concealed for protecting their privacy but the hashes of the information are not concealed as there is no danger of leaking the information from a hash file [22, 23]. Company XA wants to confirm that the provided list is accurate and has not been tempered in any way, and company XB sends the TPM quote of the file for its integrity. From the company XA end, they reconstruct the hash from the hashes and compare it with the TPM quote, a piece of match evidence that the file is original and has not been tempered otherwise manipulated. That leads to a safe decision for company XA for hiring the consultant.


## 9. Conclusion

The proposed model enhanced delegation and influenced the delegation mechanism by enabling a more fine-grained and secure process of empowering access to resources. Within the capability, our approach adds further limits on certain roles and permissions. Even if the capability has several hops, labeling the roles/permissions as sensitive prevents further delegation. Our methodology allows for high levels of collaboration between different enterprises while also limiting unwanted capability, giving the organization refine level of control over its resources. The proposed system achieves the required functionality without providing any administrative burden or manual vigilance over the system. The EAU is imparted to authenticate delegatee before access is granted by taking separation of duty and flow of sensitive permissions into account. No user is authorized to access any number of roles/permissions that he is not supposed to exercise, and the model ensures to provide access to the least number of users for performing a particular task. The devised mechanism thus also restricts the access flow for preserving privacy and secure information.



---

*Source: 8500278-2022-04-13.xml*