incorporating delegation into abac: healthcare information … · 2018. 10. 6. · incorporating...

Incorporating Delegation into ABAC: HealthcareInformation System Use Case

Khaled Sabahein Department of Computer and

Information Science University of Mississippi [email protected]

Brian Reithel Department of Management

Information Systems University of Mississippi [email protected]

Feng WangDepartment of Computer and

Information Science University of Mississippi

[email protected]

Abstract—Access control protects the systems resources againstunauthorized access via a set of policy rules. Attribute-BasedAccess Control (ABAC) is a relatively new form of access controlthat manages access control decisions based on the attributes ofusers, objects and the environment rather than the identity ofusers or the roles assigned to them. ABAC has gained significantinterest since it is considered a generic model of access control.However, existing ABAC models do not support the delegationconcept. While delegation allows the granting access rights undercertain conditions (often temporary ones), it can lead to issuessuch as: conflicting policy evaluation and user collusion. In thiswork, we present a new model for delegation in ABAC. Ourmain idea is to incorporate delegation to manage informationsharing in the healthcare information system, as one of the cloudcomputing applications, based on ABAC model. The proposedmodel is used to propagate access in order to protect resourcesby trusted users.

Keywords—ABAC, Delegation, Could Computing, HealthcareInformation system, Information Security

I. INTRODUCTION

Cloud computing has received a lot of attention in the lastfew years. It is becoming one of the bases of the IT industrydue to the simplicity of using virtual resources. It permitsthe users to have access to their data or information withouthaving them stored locally.

Delegation arises when a user needs to act on behalfof another user for accessing resources. It represents animportant key to secure information sharing across distributedcomputing environment. It also enables users to granttemporally permissions while avoiding any unauthorizedaccess and any potential for users to collude. In thehealthcare system, many professionals collaborate to provideservices; administrative personnel and a variety of healthcareprofessionals have to work together, which can lead to issuesrelated to the collaborative sharing of patient information. Ourwork examines the issues of delegation in Attribute-BasedAccess Control through this healthcare use case in order tofind a solution to these problems.

Generally, delegation is based on three principal elements:Delegator (Who is doing the delegating?), Delgatableelement (What is being delegated?) and Delegatee(Where/who are the elements being delegated to?). Inthis paper, our proposed delegation model is based on

Group Membership strategy [1]. In this end, we extend theHierarchical Attribute-Based Access Control (HGABAC)model [2] to support our Group membership delegationapproach. Furthermore, we formalize the revocation ofdelegation with respect to all dimensions presented in [3].Farthermore, we formulate the ABAC Policy language andwe propose an ARCHITECTURE to support delegation.

The rest of the paper is organized as follows: Section 2defines the problem and the resolution methodology. Relatedwork are presented in section 3. Section 4 overviews prelim-inaires that we consider in this paper. Section 5 presents thesuggested delegation model. In section 6 we spesify the ABACpolicy language and the architecture to support delegation.Finally, the conclusion and expected future work are drawnin section 7.

II. PROBLEM DEFINITION AND RESOLUTIONMETHODOLOGY

Consider the case of a collaboration session where eachorganization’s data should be accessible by individuals fromother organizations so that they can collaborate in a givendiagnosis. Our proposed scenario is depicted in figure 1,where Alice, who is under the care of a neurologist. Wesuppose that Alice becomes pregnant, which leads her tobecome a patient of a gynecologist. The both doctors mustshare Alice’s information in order to collaborate on hercare. Furthermore, one of the doctors may consult anotherspecialist in a given hospital, and as a results, this specialistthen needs access to Alice’s information as well.

In a dynamic and collaborative environment systems suchas cloud computing, it is difficult to predict which datacan be shared, when it can be shared and with whom. Itis also difficult to revoke the sharing of data when it isno longer needed. Delegation represents an important keyto secure information sharing across distributed computingenvironment, and also enables to users to grant temporarypermissions. In this way it avoids unauthorized access.

Delegation has been developed within several access controlmodels such as RBAC. RBAC (Role-Based Access Control)is an approach to restricting system access to authorized

Int'l Conf. Security and Management | SAM'18 | 291

ISBN: 1-60132-488-X, CSREA Press ©

Fig. 1. Organization involved in the collaborative diagnosis.

users, where the delgator and the delegatee are usersand the access control element being delegated is a set ofpermissions. While ABAC (Attribute-Based Access Control)model lacks a formal specification for controlling delegation,ABAC is based on attributes, thus make it more complexto deal with. Another issue with ABAC is the problem ofrevocation, which also is not formalized. It is necessary tocontrol evaluation of policies to ensure that permissions arerevoked when the delegatee’s access is removed due to achange in attributes, time expiration or delegator revocation.

The main idea in this work is to incorporate delegationto manage information sharing in the healthcare informationsystem based on ABAC model (Attribute-Based Access Con-trol). Delegation is used to propagate access in order to protectresources by trusted users. The contribution of this work canbe summarized as follows:• A formal specification for delegation in Attribute-Based

Access Control model.• A formal specification for revocation.• A formal specification of ABAC policy language to

support delegation.

III. RELATED WORK

Organizations implement access control system in orderto protect resources and information sharing within a highlydistributed systems. Various models of access control havebeen proposed, including Access Control Lists (ACL), Team-based Access Control (TMAC) [4], Task-Based Access Con-trol (TBAC) [5] and Role-based access control (RBAC) [6].

Delegation is a mechanism for extending access rightsavailable to one user to another user. It represents an importantfactor for securing distributed computing environment. further-more, it simplifies the managing of temporary assignment ofroles and permissions especially in dynamic and collaborativework environment.

In RBAC research, several delegation models have beenproposed to apply delegation into RBAC model. These modelspermit to assign roles or partial permissions under certainpredefined constraints and revocation conditions. An early

work on the subject [7] identified the important considerationsfor delegation in RBAC. RBDM0 as a delegation modelwas proposed by [8], which is based on the RBAC0 modelof the RBAC96 family. The PBDM [9] model supportsboth role and permission level delegation, with features ofmulti-step delegation and multi-option revocation. Anotherdelegation model (RDM2000) for role-based access controlis presented in [10], RDM2000 considers roles hierarchiesand support multi-step delegation as well as revocation. Thecommon feature between the models mentioned above, is theuse of the relation can delegate for controlling delegations(i.e., authorizing delegation). The model presented in [11]is considered to be more flexible. Where authors add newrelation can receive, which aims better flexibility, greatercontrol and ease of management. Furthermore, they studieda temporary transfer delegation. In a nutshell, the modelsdiscussed above try to propose systematic approaches tospecify delegation and revocation in context of role-basedaccess control models.

On the other hand, concerning trust management systems,the concept of delegation is a prime example of the applicationof trust transitivity. A variety of trust management systemshave been proposed to manage decentralized authorization.To verify whether a subject is authorized access to a givenresource, these systems are based on either certificate chaindiscovery for the SPKI/SDSI system [12] [13] or for role-based trust management [14]. Other systems are based onthe trust relationship [15]. The systems mentioned aboveconstruct the proof of authorization in a centralized manner,while in [16] the certificate are stored in distributed mannerand the proof of authorization is constructed likewise.

To the best of our knowledge no efforts to date have beenmade to apply a delegation model to Attribute Based AccessControl (ABAC) model in cloud computing environment.In [1], the authors offer a preliminary investigation intostrategies for incorporating delegation into existing ABACmodels and discuss the potential trade-off associated with eachstrategy. Strategies are created by evaluating the combinationsof delegators, delegatable access control elements anddelegatees. As a result, delegation strategies are categorizedinto Permission, Attributes and Group Membership delegation.

Control evaluation of policies to ensure that permissionsare revoked when the delegators access is removed due to achange in attributes, time expiration or delegator revocation,needs to be taken into account. Another aspect is the dynamicfeature of the system, where adding or removing objects fromthe system may change its behavior, and as a results changingon delegation operations.

IV. PRELIMINARIES

A. Basic elements of delegation

The delegation process is composed of three access controlcomponents; a delegator, a delegatee and a delegatable access

292 Int'l Conf. Security and Management | SAM'18 |


control element. Under a set of constraints a delegator grantsto a delegatee an access control element, for instance aset of permissions. In traditional access control models asRBAC model, delegation is straightforward, the delegator anddelegatee are typically users and the delegatable element iseither a set of permissions [8]. The ABAC model presentsnew possibilities for delegators, delegatees and delegatableelements [1]. We define in this section the main delegationcharacteristics that we consider to define our delegation model:

• Delegator : The delegator can be either a user or usergroups.

• Delegatee: As presented in [1], the delegatee is notlimited to users. It can also be user groups, attributes orpolicy depending on the desired scenario. Since ABACmodel is based on attributes for the access decision, weconsider attributes as delegatee element. As a result,all users that are directly assigned to the same attributealso become delegatees, and are granted the delegatableelement being delegated. For instance, if a permission Pis delegated to the attribute ”specialist={cardiologist}”(an attribute named specialist with the value cardiologist),all users that are assigned the attribute specialist with avalue of cardiologist will be delegated the permission P .

• Delegatable access control element: Delegatableelement is the most important characteristic ofdelegation process. The suitable delegatable elementswe can consider are: Attributes, Permissions and GroupMembership. In our case we consider Group Membershipas the element to be delegated.

• Type of delegation: The delegator can delegate theentire of his permissions that he obtained from satisfyinga given policy. In this case, a total delegation is granted.Otherwise, the result is partial delegation, where thedelegator delegates only a subset of his permissions. Inour model we consider the total delegation.

• Level of delegation: This feature defines whether eachdelegation can be further delegated and how manytimes (one step or multi-step delegation). The delegationlevel addressed in this model is multi-step delegation.Therefore, the delegated Group Membership can befurther delegated.

• Revocation: The process of revocation is used forterminating the delegation process. In the simple case,any delegator can revoke the delegation he made.Otherwise, any delegation has a time (duration T ),and once the assigned time expires, the delegationis automatically revoked. The revocation might stillbe executed by the delegator even if the duration ofdelegation is still valid.

Fig. 2. HGABAC components and relations [2]

In this work, we consider user groups as Delegator, andsince HGABAC [2] is the only model that support the groupconcept, we adopt this model (HGABAC) to our proposedapproach.

B. HGABAC Model: Basic Elements

Basic elements and definitions are depicted in figure 2:• S : Set of subjects.

• Subject Attributes (SA): set of attribute name,type pairs that may be applied to users such that :∀a ∈ SA : a = (name, type).

• Subject Groups (SG): set of subject groups, whereeach group is a tuple: g = (name, s ⊆ S, p ⊆ SG),where name is a globally unique identifier, s is the setof members of the group, and p is the set of the group’sparents in the subject group graph.

• Direct Subject Attribute Assignment (SAA): isa relation containing subject, attribute name andvalue triples such that: ∀saa ∈ SAA : saa = (s ∈S, att name, values).

• Subject Group Attribute Assignment (SGAA): SGAArelation containing subject group name, attribute nameand value triples such that: ∀sgaa ∈ SGAA : sgaa =(group name, att name, values).

• member(x): Mapping a subject to the set of groups forwhich he is a member: member(x) = {(name, s, p)} ∈SG ∧ x ∈ s.

• direct(x): Set of attribute directly assigned to a user orgroup in the SAA, SGAA relation:

– if x ∈ S, direct(x) = (n, v) | (x, n, v) ∈ SAA}– if x ∈ GS, direct(x) = (n, v) | (name(x), n, v) ∈

SGAA}• inherited(x): The set of attributes assigned indirectly

through the group hierarchy or group membership.



• effective(x): The set of all attributes inherited or directlyassigned:

effective(x) = direct(x) ∪ inherited(x)

V. PROPOSED DELEGATION MODEL

A. Delegation Model

The delegation model proposed is based on Group Mem-bership strategy [1]. Given a subject s and the Group Mem-bership denoted GM(g), where g is a subject group such thatg = (gn, SM, p). The delegation d is defined as a tuple:

d = (i, s, attr,GM(g), v, b)

Where, i is the delegation identifier, s is the delegator,attr is a set of attributes (i.e., delegatee), and GM(g) is theaccess right being delegated (i.e., Group Membership). v isthe validation lifetime (e.g., time duration). And b ∈ {−,+},where the tuple of the form d = (i, s, attr,GM(g), v,+)means that any subject assigned directly with attr can delegatefurther GM(g). We present the delegation as follow:

di : sGM(g)b−−−−−→

vattr

{d1, ..., dn} ∈ DL, where DL specifies the delegationlist (i.e., the delegation list might be used for the historicalpurpose, as well as verification). The delegation di is valid ifs is a member of the group g such that:

member(s) = {(gn, SM, p)} ∈ SG ∧ s ∈ SM .

Example 1. Consider our previous scenario presented insection II. For instance, we consider the following elements:• Subject s = Doctor• Group membership GM(g1), where g =

(Gynecologist, {doc1, ..., docn}, Chiefofsurgery)• Delegatee Attributes attr = {position =

nurse, experience = 15}• validation lifetime v = Accouchment• b = −, the subject who has attr cannot delegate further

GM(g1).Therefore, the delegation formula is :

d1 : DoctorGM(g1)

−

−−−−−−−−−→Accouchment

{position =

nurse, experience = 15}

Proposition 1. If there exist a subject s′ having the set ofdirect attribute attr, then s′ belongs to the set of subjectmembers SM , and the effective attributes of s′ are the unionof its direct and inherited attributes. Formally:

if (s′ ∈ S) ∧ (attr ⊆ direct(s′)) −→ (s′ ∈ SM)∧(effective(s′) = direct(s′) ∪ inherited(s′))

Example 2. Figure 3 shows an example of group membershipdelegation. In this example Alice is a member of the Oncologyteam. Alice delegates to the set of attributes (role =”undergrad”) the group membership GM(Oncology team).Since (role = ”undergrad”) ⊆ direct(Dave), therefore,Dave is granted the GM(Oncology team).

Fig. 3. Example of group membership delegation

The purpose of delegating attributes is to provide greaterflexibility and allow delegation to users whose identity isunknown (Proposition 1).

B. Revocation

delegation has a specified lifetime or may be revokedbefore the delegation ends. After revocation, attributes thatare assigned to subject, must be updated to prevent anysubsequent use of the delegated access right. We present therevocation with respect to two dimensions: propagation anddominance [3]. Revoking delegation depends on its type.Figure 4 shows the different delegation forms regarding thecharacteristics discussed in section IV.

Fig. 4. Delegation Forms

Consider a delegation d defined as d =(i, s, attr,GM(g), v, b) where g = (gn, SM, p). Supposed is revoked (i.e., either by the delegator or expiration oflifetime). The effect of such a revocation is as follow:

• Propagation: This dimension distinguishes revocationsaccording to space. If a delegation is revoked and thisdelegation had been used to generate other delegations,the effect of revocation can be either local (non-cascading



Fig. 5. Delegation chain as a linear list

revocation) or global (i.e., subsequent delegations are alsorevoked).

– Local Propagation: Local revocation intended toaffect only the direct recipient.{

SM ← SM\{∀s ∈ S | attr ⊆ direct(s)}∀s ∈ S | attr ⊆ direct(s)→ effective(s) = direct(s)

For example, as show in figure 5, when s2 is nolonger allowed to grant a GM(g) allowed by d1.Hence:SM ← SM\{s2} and effective(s2) = direct(s2)

– Global Propagation: Global revocation intendedto affect all the resulting delegation. According todelegation form shown in figure 4, the delegationchain can be either as a list (Figure 5) or as a tree(Figure 6). In the former case, we need to updateSM by deleting all subject resulting in {d1, ..., dn}from SM . In the latter case, we need to delete allsubject rooted at d1 ∈ DL from SM .

• Dominance: This dimension deals with the conflictsthat arise when the subject has been granted the samepermissions from different delegators (i.e., a subject losesa permission in a revocation while it still has this permis-sions from other grantors).A subject can be granted a GM(g) from multipledelegators. In the figure 7, the revocation for s2 can bedirect (weak revocation, from s1), or indirect (strongrevocation, from s1 and s3). Formally:

In the first case, s2 still has the right GM(g):s2 ∈ SM ∧effective(s2) = direct(s2)∪ inherited(s2)

In the second case, s2 will be completely blocked fromGM(g):SM ← SM\{s2}effective(s2) = direct(s2)

VI. ABAC POLICY SPECIFICATION AND SYSTEMARCHITECTURE

In this section, we define the delegation operations as wellas the possible relations to ensure delegation. Furthermore, wedefine an ABAC specification language to support delegationthat we have proposed in previous section. Firstly, we give theformal definition of permissions, since delegation is based onassigning a set of permissions.

Definition 1. (Access Permissions) Given an access control,we define a set of permissions regarding the way a given

Fig. 6. Delegation chain as a tree

Fig. 7. Example of a delegation granted from multiple delegators

subject s obtained them.

• PERM : A set of permissions.• DirectPerm: A set of permissions obtained directly from

satisfying the policy.• DPerm: A set of permissions allowed to be delegated

(Delegable Permissions).• NDPerm: A set of permissions that can not be delegated

(Non-Delegable Permissions).• EffectivePerm: A set of permission obtained directly

and through delegation. Where:EffectivePerm = DirectPerm ∪ DPerm andDirectPerm ∩DPerm = ∅

A. Delegation operations

Delegation operations required different operationsregarding the purpose of the access control to be implemented.In this end, we distinguish two operations:

grantPerm (s, s′, PERM ): The delegator s grants thepermissions PERM to s′. The delegator may continue to usePERM . For example, in a distributed healthcare system, thisis useful when a collaboration is needed to corporate and sharethe same permission in order to perform a given diagnosis.

Example 3. grantPerm (doctor, nurse, ”can read PR of Al-ice”): The doctor grants the permissions to read the personalrecord of Alice to nurse.

transfPerm (s, s′, PERM ): The delegator s transfers thepermissions PERM to s′. The delegator may no longeruse PERM . For example, if Alice’s gynecologist doctor ischanged, no need to rewrite the policy, a simple transfer ofpermissions if needed.



Example 4. transfPerm (nurse1, nurse2, ”can read PR ofAlice”): The nurse1 transfers the permissions to read thepersonal record of Alice to nurse2, and nurse1 has no longerthis permission.

We assume that our model specifies whether the delegationof permissions is permitted, as well as evaluation to determinewhether the delegation is valid to be performed. Specificationof delegation arises different issues:

1) Is a delegator authorized to delegate the permissions hechose?

2) Can a permission be delegated?

B. Delegation relations

To address delegation issues, we formalize delegationrelations in order to control delegation process:

can-delegate relation: Specifies whether a subject is au-thorized to delegate a permission. can-delegate ⊆ S ×PERM : (s, perm) ⊆ can-delegate specifies that a subjects ∈ S is authorized to delegate the permission perm ifperm ⊆ DirectPerm, Where DirectPerm denotes the set ofpermissions assigned directly to s .

Example 5. Consider a set of subject S = Gynecologistsand the relation can-delegate ⊆ Gynecologists× ”canread PR of Alice”. Suppose s = Radiologist /∈ S: s cannotdelegate the permission ”can read PR of Alice”.

can-receive relation : Specifies whether a subject s′ is au-thorizes to receive the permissions. can-receive ⊆ PERM ×C : (perm,C) ⊆ can-receive means that subject s is autho-rized to receive a delegation of permission perm if s satisfiesC, where C is a set of conditions to be satisfied to receive thedelegation.

Example 6. Consider a set of subject S = Neurologists andthe relation can-receive ⊆ Neurologists× ”can read MRIof Alice”. Suppose s = administrator /∈ S: s cannot receivethe permission ”can read MRI of Alice”.

C. ABAC policy specification

An ABAC policy P is defined as a set of rules:P = {r1, ..., rn}. Each rule ri ∈ P is defined by three typesof attributes [17]:

- Subject attributes: the user or the process that takes anaction on a resource. Denoted ATTR(s).

- Resource attributes: the entity that is acted upon by asubject. Denoted ATTR(r).

- Environment: the operational, technical or situationalcontext in which the information access occurs. DenotedATTR(e).

ABAC model defines policies that control access toresources. We specify two types of rules, basic rules and

delegation rules.

A policy P = {r1, r2, ..., rn} is made up of a set of basicrules. A rule r decides whether a subject s can access aresource r in an environment e. For this purpose, a Booleanfunction is evaluated based on the values of all the attributesof s, r and e. Thus, the Policy rule that regulates this accessis expressed as follows [18]:

Rule : can action(s, r, e)←f(ATTR(s), ATTR(r), ATTR(e))

Where action presents the operation being requested (e.g.read, create, delete, ...)

Example 7. Consider the following rule, where a neurologistcan read the MRI scan between 8h00 and 16h00:

Rule : can read(s, r, e)←f(neurologist),MRI, [8h00− 16h00])

In order to support delegation of permissions, we specifydelegation rules which control and enforce delegation. Delega-tion rules takes the form f ←− . We assume that the delegationrules are always true .

Rule : can delegate(s, s′, PERM)←−

where s, s′, and PERM are the subject delegator, thesubject delegatee and a set permission respectively. This ruleis derived from the can-delegate relation. This rule means thats can grant to s′ the set of permission PERM .

D. System Architecture

In order to implement ABAC policy, we consider eXtensibleAccess Control Markup Language (XACML) [18] is the mostconvenient way to express ABAC policies. XACML definesan XML schema that supports the ABAC model. XACMLassumes an architecture containing three main components:

Fig. 8. Delegation Architecture

• PEP (Policy Enforcement Point): is responsible of ex-tracting attributes from the request and sending them tothe PDP.

• PDP (Policy Decision Point): searches in the policyrepository (PAP: Policy Administration Point) whose



attributes match the request. Based on the effect of thematched rule, the PDP sends the final decision to the PEP.

• PAP (Policy Administration Point): is responsible formanaging the policies in the policy repository (addingnew policies and rules). Figure 9 presents an example ofa rule in XACML.

Fig. 9. Example of a rule in xacml

In order to support delegation, we proposed adding a newcomponent that contains delegation rules. The proposedarchitecture is depicted in Figure 8:

• Delegation Policies: is the architectural entity that isused to manage delegation policies that PDP evaluates.In general, it enables the authoring, deployment, changemanagement etc, of the delegation policies.

Given an access request, the PEP will extract subject,resource and environment attributes. The PDP evaluates therequest in its normal case with the PAP that contains securityrules. In case any rule matches the request, PDP returns theresponse to the PEP. Otherwise PDP searches in the policyrepository responsible for delegation for any delegation rulethat matches the access request. The main advantage of theproposed delegation architecture is supporting both normalbehavior of the access control and delegation process.

VII. CONCLUSION

Delegation is an important method to perform resiliency andflexibility in access control systems. It is mainly challenging toadopt delegation in ABAC (Attribute-Based Access Control)model because it does not support delegation in its process.To remedy this, We have proposed a preliminary modelfor delegation in ABAC. In particular, we have proposed agroup membership strategy. We have also shown how differentforms of delegation can be revoked. As future work, we aimextending the proposed model to deal with issues related todelegation such as: conflicting policy evaluations and usercollusion. As well as implement the proposed model.

REFERENCES

[1] D. Servos and S. L. Osborn, “Strategies for incorporating delegationinto attribute-based access control (abac),” in International Symposiumon Foundations and Practice of Security. Springer, 2016, pp. 320–328.

[2] ——, “Hgabac: Towards a formal model of hierarchical attribute-based access control,” in International Symposium on Foundations andPractice of Security. Springer, 2014, pp. 187–204.

[3] A. Hagstrom, S. Jajodia, F. Parisi-Presicce, and D. Wijesekera,“Revocations-a classification,” in Computer Security Foundations Work-shop, 2001. Proceedings. 14th IEEE. IEEE, 2001, pp. 44–58.

[4] R. K. Thomas, “Team-based access control (tmac): a primitive forapplying role-based access controls in collaborative environments,” inProceedings of the second ACM workshop on Role-based access control.ACM, 1997, pp. 13–19.

[5] R. K. Thomas and R. S. Sandhu, “Task-based authorization controls(tbac): A family of models for active and enterprise-oriented autho-rization management,” in Database Security XI. Springer, 1998, pp.166–181.

[6] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, “Role-based access control models,” Computer, vol. 29, no. 2, pp. 38–47, 1996.

[7] E. Barka and R. Sandhu, “Framework for role-based delegation models,”in Computer Security Applications, 2000. ACSAC’00. 16th AnnualConference. IEEE, 2000, pp. 168–176.

[8] E. Barka, R. Sandhu et al., “A role-based delegation model and someextensions,” in 23rd National Information Systems Security Conference.Citeseer, 2000, pp. 396–404.

[9] X. Zhang, S. Oh, and R. Sandhu, “Pbdm: a flexible delegation model inrbac,” in Proceedings of the eighth ACM symposium on Access controlmodels and technologies. ACM, 2003, pp. 149–157.

[10] L. Zhang, G.-J. Ahn, and B.-T. Chu, “A rule-based framework for role-based delegation and revocation,” ACM Transactions on Information andSystem Security (TISSEC), vol. 6, no. 3, pp. 404–441, 2003.

[11] J. Crampton and H. Khambhammettu, “Delegation in role-based accesscontrol,” International Journal of Information Security, vol. 7, no. 2, pp.123–136, 2008.

[12] J.-E. Elien, “Certificate discovery using spki/sdsi 2.0 certificates,” Ph.D.dissertation, Massachusetts Institute of Technology, 1998.

[13] S. Jha and T. Reps, “Analysis of spki/sdsi certificates using model check-ing,” in Computer Security Foundations Workshop, 2002. Proceedings.15th IEEE. IEEE, 2002, pp. 129–144.

[14] N. Li, W. H. Winsborough, and J. C. Mitchell, “Distributed credentialchain discovery in trust management,” Journal of Computer Security,vol. 11, no. 1, pp. 35–86, 2003.

[15] M. Blaze, J. Feigenbaum, and M. Strauss, “Compliance checking in thepolicymaker trust management system,” in International Conference onFinancial Cryptography. Springer, 1998, pp. 254–274.

[16] S. Abdi and J. Herbert, “An algorithm for distributed certificate chaindiscovery in open environments,” in Proceedings of the 30th AnnualACM Symposium on Applied Computing. ACM, 2015, pp. 2292–2298.

[17] E. Yuan and J. Tong, “Attributed based access control (abac) for webservices,” in Web Services, 2005. ICWS 2005. Proceedings. 2005 IEEEInternational Conference on. IEEE, 2005.

[18] A. Anderson, A. Nadalin, B. Parducci, D. Engovatov, H. Lockhart,M. Kudo, P. Humenn, S. Godik, S. Anderson, S. Crocker et al.,“extensible access control markup language (xacml) version 1.0,” OASIS,2003.



incorporating delegation into abac: healthcare information … · 2018. 10. 6. · incorporating...

Documents