Comparing and Integrating Break-the-Glass and Delegation in
Role-based Access Control for Healthcare
Ana Ferreira
1
and Gabriele Lenzini
2
1
CINTESIS - Centre for Health Technologies and Services Research, Faculty of Medicine,
University of Porto, Rua Dr. Pl´acido da Costa, 4200-450 Porto, Portugal
2
SnT - Interdisciplinary Centre for Security, Reliability and Trust,
University of Luxembourg, 4 rue A. Weicker, L-2127 Luxembourg, Luxembourg
Keywords:
RBAC in Healthcare, Break The Glass, Delegation, Access Control.
Abstract:
In healthcare security, Role-based Access Control (RBAC) should be flexible and include capabilities such
as Break-the-Glass and Delegation. The former is useful in emergencies to overcome otherwise a denial of
access, the latter to transfer rights temporarily, for example, to substitute doctors. Current research studies
these policies separately, but it is unclear whether they are different and independent capabilities. Motivated
to look into this matter, we present a formal characterization of Break-the-Glass and Delegation in the RBAC
model and we inquire on how these two policies relate. After giving arguments in favour of keeping them
apart as different policies, we propose an RBAC model that includes them.
1 INTRODUCTION
The RBAC model (Sandhu et al., 1996) is a
widespread standard for the administration of ac-
cesses in organizations with a high number of em-
ployees each having specific roles. Access control
policies are defined per role instead of per simple em-
ployee. In healthcare, RBAC has been customized to
handle situations where doctors find themselves re-
questing access to data that they should not normally
access (Ferreira et al., 2007); in such situations a role
must be given allowances that the standard policies
would deny. This may happen when a doctor inter-
vening in life-saving emergencies, substituting a col-
league, or consulted for a second opinion needs to ac-
cess the records of another doctor’s patient. To work
with emergences RBAC has been extended with a
feature called Break-the-Glass (BTG) (Ferreira et al.,
2006): it allows a role to overrule the restrictions that
normally constrain the access to data but the viola-
tion is recorded and the violator usually bound to ful-
fil specific obligations (Ferreira et al., 2009). To work
with referrals, RBAC has been extended with an oper-
ation called Delegation (DELG) (Barka and Sandhu,
2000; Wang and Osborn, 2006; Barka and Sandhu,
2007): it enables subjects to transfer permissions (po-
tentially all the permissions linked to a role) to other
subjects.
BTG and DELG have already been studied in the
context of RBAC but the works that consider one do
not study the other (Barka and Sandhu, 2000; Wang
and Osborn, 2006; Barka and Sandhu, 2007; Cramp-
ton and Khambhammettu, 2008; Ferreira et al., 2009).
The few works that address both i.e., (Crampton and
Morisset, 2011; Krautsevich et al., 2012) are not mo-
tivated bycomparingthe two capabilities but rather by
showing how to implement break-the-glass as auto-
delegation.
Understanding whether BTG and DELG can co-
exist as independent capabilities is instead what mo-
tivates the work we report on this paper. To shed
light on the matter we need to compare the definitions
and implementations of these two policies and reason
on whether and how they relate. Thus we study the
RBAC models that express those policies separately;
after giving an argument in favour of the co-existence
of the two policies, we propose a RBAC model that
combines them and study the security implications
that this combination has. To our knowledge such re-
search is unprecedented.
Contribution. This paper describes the RBAC
model in preparation to discuss and compare BTG
and DELG. The paper’s approach is to reason on the
syntax and on the operational semantics of the poli-
cies in terms of the procedure that checks whether a
request is authorized (§3). In the specific context of
healthcare access control, this paper studies the re-
Ferreira, A. and Lenzini, G.
Comparing and Integrating Break-the-Glass and Delegation in Role-based Access Control for Healthcare.
DOI: 10.5220/0005683600630073
In Proceedings of the 2nd International Conference on Information Systems Security and Privacy (ICISSP 2016), pages 63-73
ISBN: 978-989-758-167-0
Copyright
c
 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
63

quirements that make a set of policies secure. Secure
here means free from ambiguities that would let one
user gain a permission without breaking-the-glass on
it and without receiving legitimately the permission
by delegation (§4–§5): due to the nature of BTG and
DELG, the first permitting controlled exception and
the second spreading permissions, identifying when
violations can happen is not obvious.
This paper questions whether BTG and DELG can
be distinct or not. At least in the medical domain
where managing and assigning permissions is decen-
tralized, it turns out that there is an argument for keep-
ing the two policies apart, which leads to more expres-
sive security policies. This is a novel argument with
respect to the state of the art (§2). Thus, this paper
proposes a new RBAC model that supports policies
with interleaved BTG and DELG (§6) and shows, via
examples, that this gives flexibility in writing access
control policies for coping with the heterogeneous af-
fairs of the daily practise in healthcare. This paper
also identifies two relevant security requirements for
this new model: policy makers can use them to write
security-by-design policies.
2 RELATED WORK
This work relates with previous research on access
control models for delegation and break-the-glass.
Delegation has been widely studied in the context
of RBAC models. The majority of the works define
the capabilities of this operation (Wainer, 2005; Wang
and Osborn, 2006; Barka and Sandhu, 2007; Cramp-
ton and Khambhammettu, 2008; Li and Wang, 2008;
Hasebe and Mabuchi, 2010) but only a few of them
trial and test delegation in real healthcare scenarios.
Research on break-the-glass spans from the def-
inition of concepts (Rissanen et al., 2006; Rostad
and Edsberg, 2006; Brucker and Petritsch, 2009) to
the implementation of this feature in a hospital sys-
tem (Ferreira et al., 2009).
With respect to these works, we discuss break-the-
glass and delegation with the aim of understanding
whether they can be combined and integrated. Un-
derstanding the relation between break-the-glass and
delegation is a research goal not addressed previously.
The few works that discuss break-the-glass and del-
egation with RBAC intend to show how to imple-
ment break-the-glass as auto-delegation on a permis-
sion (Crampton and Morisset, 2011). Auto-delegation
is authorized only when no other role that possesses
legitimately the permission is present in the system,
and resolving whether a role is authorized to auto-
delegate a permission may become conditional to the
probability that such a role is available (Krautsevich
et al., 2012). Both works do not argue (it is not in
their research’s scope) whether there are interpreta-
tions of one capability that cannot be captured by the
other; consequently, they do not study, as we do, the
consequences of using them together within the same
RBAC model.
We are motivated to clarify exactly this relation
and to discuss the security implications of having
break-the-glass and delegation coexisting in the same
framework. Our intuition, an argument that we de-
velop in this paper, is that break-the-glass —more apt
to cope with not necessarily unforeseen but however
exceptional situations— and delegation —suitable to
plan transfer of rights— are different features (thus
different policies) that call for different security re-
quirements.
That there may be a distinction between delega-
tion and break-the-glass seems emerging from ex-
isting implementations of the Break-the-Glass Role-
based Access Control (BTG-RBAC) model (Ferreira
et al., 2009). Here, breaking-the-glass on a permis-
sion mimics what happens when one breaks a pro-
tection glass. Glass-protected permissions become
and remain accessible until the glass is repaired (i.e.,
the protection-status is reset). Users with the same
role as the one who broke the glass can access the
resource without obligations: obligations will come
again when the glass is restored. Allowing roles to
take advantage of a broken glass without obligations
seems to invite for abuses, which we intend to avoid,
but even if we assume an implementation that mim-
ics less faithfully what happens to a real glass (see
§ 4) Ferreira et al.’s proposal of the break-the-glass
diverges from auto-delegation.
There are still other works that define ways to
extend BTG-RBAC, but their applicability is limited
to specific domains such as Wireless Sensor Net-
works (Maw et al., 2014) and Cloud Computing (Ra-
jesh and Nayak, 2012). There is no understanding
about how break-the-glass and delegation relate in
general and in the medical domain in particular.
3 RBAC AND ITS EXTENSIONS
This section recalls the basic RBAC models in a com-
mon and simple formalism with the goal to intro-
duce the approach followed throughout the paper: de-
fine the policy language and its operational semantics
by specifying how the authorization procedure —the
procedure that checks whether a request from a user
should be allowed or denied— works. In the same
formalism, this section describes RBAC with Break-
ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy
64

the-Glass and RBAC with Delegation, together with
a specific healthcare use-case of their application in
practice.
This allows us to discuss and compare two rel-
evant security requirements for Break-the-Glass and
Delegation and to discuss whether and how the poli-
cies can coexist without introducing vulnerabilities in
the security outfit that the policies are meant to supply
for the system.
Assumptions. We assume that there is no central-
ized management by a third-party’s administration:
all operations are performed by users i.e., doctors, pa-
tients or their delegates. This is because in the health-
care domain, users need to be independent in using
the system in order to cope with sudden and dynamic
situations. A third-party would introduce one more
step in the process, potentially compromising effec-
tiveness and efficiency.
We assume policies are set at start-up, e.g., by the
owner or the manager of the data. This initial policy
set imprints the system’s security.
We assume that break-the-glass and delegation are
applied on permissions and not on roles. This fine-
grained option fits better to the variety of situations
often decided on a need-to-know basis that character-
ize the daily accesses by the healthcare professionals.
3.1 Permissions, Operations, Objects
A permission tells what operation is permitted on
what object. Let OPS be the set of operations and
OBS the set of objects; the set of permissions is
PRMS ⊆ OPS× OBS. Each p ∈ PRMS has the form
(op,obj), where op ∈ OPS and obj ∈ OBS. Having
permission (op,obj) (e.g., (read,f)) means be al-
lowed to execute operation op (i.e., read) on object
obj (i.e., f), or equivalently said, to be allowed to ex-
ecute op(obj) (i.e., read(f)).
3.2 RBAC Basic Models
The simplest RBAC models are called RBAC
0
and
RBAC
1
(Sandhu et al., 1996).
RBAC
0
consists of several sets: SESSIONS of ses-
sion, ROLES of roles, USERS of users, and PRMS of
basic permissions (we qualified permissions in PRMS
as “basic” to distinguish delegation and break-the-
glass, which we introduce later). RBAC
0
comprises
the following relations: UA ⊆ USERS × ROLES, the
roles that users can play; PA ⊆ PRMS × ROLES, the
permissions roles have. Set R
u
= {r : (u,r) ∈ UA}
specifies the roles that a user u can play.
RBAC
1
is slightly more elaborated than RBAC
0
.
It comes with a closed-under-transitivity partial order
≤ on ROLES × ROLES that defines a hierarchy on
roles. Set ↓(R
u
) = {r ∈ ROLES : r ≤ r
′
,r
′
∈ R
u
} is the
set of all roles and all sub-roles that user u can play.
Within one session, a user u can only activate one of
its roles, r
u
∈ R
u
. Set ↓(r
u
) = {r ∈ ROLES : r ≤ r
u
}
defines u’s role and sub-roles according to the hierar-
chy. All users and their active permissions in a ses-
sion are stored in a policy set π ⊆ USERS× PRMS,
π = {(u, p) | u ∈ USERS, r ∈ ↓(r
u
),(p, r) ∈ PA}. To
determine whether user u has permission p is simply
a matter of checking π on whether p is assigned to
one of the roles that u can play. We let the predi-
cate Auth
π
(u, p) do this job: it evaluates false (ff) for
‘permission denied’, and true (tt) for ‘permission al-
lowed’.
Auth
π
: USERS× PRMS → {ff,tt}
Auth
π
(u, p)
def
=
(
tt, if (u, p) ∈ π
ff, otherwise
Obligations. These are requests for actions trig-
gered when a user tries to access a resource (Zhao
et al., 2007). To handle obligationswe need to slightly
change PRMS to OPRMS = PRMS×2
OBGS
as well as
Auth
π
to make it return a set o of obligations:
Auth
π
(u, p)
def
=
(
(tt,o) if (u, p) ∈ π
(ff,o), otherwise
To simplify the notation, in the remainder we omit
obligations, assuming that they can be introduced any
time, with no theoretical difficulty.
3.3 Running Example (Prologue)
We motivate the use of BTG and DELG in a run-
ning example. We consider a situation that is de-
scribed in the ISO standard (ISO/TS, 2009). The ac-
cess control is exercised with roles, which include
healthcare professionals and the patient or the pa-
tient’s guardian. The protected resource is the Elec-
tronic Health Records (EHR). EHR are used to keep
track of patients’ medical history, together with lab
tests and demographics. EHR can be shared by differ-
ent institutions and allow for both decentralised and
centralised access to the whole data base or part of it
by healthcare professionals and patients.
Our use case has four roles (see Table 1):
Dr. John, the doctor; Rachel, Dr. John’s patient;
Michel, Dr. John’s assistant; and Dr. Mario, a col-
league that occasionally substitutes for Dr. John.
Rachel has received the result of her blood tests and
she is positive to HIV, a worrisome outcome. Al-
though she knows that false positives can happen,
Comparing and Integrating Break-the-Glass and Delegation in Role-based Access Control for Healthcare
65

Table 1: Actors in our use case.
Dr. John The doctor
Rachel Dr. John’s patient
Michel Dr. John’s assistant
Dr. Mario Dr. John’s substitute
she hastily tries to contact Dr. John to discuss the
next steps. But Dr. John is travelling and cannot be
reached.
Michel however has been given permission to put
Dr. John’s patients in contact with Dr. Mario. When
that happens Dr. Mario needs access to Dr. John pa-
tient’s EHR (in this case to Rachel’s blood test) and
retain that right at most until Dr. John’s return.
This situation can be handled in various ways.
Dr. John can entrust Dr. Mario directly and delegate
him as soon as he leaves. Or he can entrust Michel,
and let her have the right to delegate the permission
to Dr. Mario when that comes into need. These and
other solutions can be implemented using delegation,
break the glass, or both. For instance, Dr. John can
entrust Michel, to break-the-glass on transferring the
right to read Rachel’s data to Dr. Mario. The use of
BTG here, is because Dr. John wants neither Michel
to have the right to read herself nor Dr. Mario to gain
the right before time; moreover, he intends the dele-
gation to Dr. Mario be happening only when patients
cannot really wait for his return. Dr. John knows that
obligations coming with the BTG will restrain Michel
from abusing that right.
4 BREAK-THE-GLASS (BTG)
BTG allows to overrule the enforcement mechanism
which would normally deny access. The violation
must happen justifiably and controllably, so BTG has
been integrated into RBAC with obligations: breaking
has consequences, for instance, alerting a responsible
party.
We write a BTG’s permission as BTG(p), where
p = (op, obj) is also a permission. So BTG(p) stands
for (btg.op,obj), where btg.op is intended to be
the operation “break-the-glass on op”. For instance,
btg.read is “break-the-glass on read”.
All RBAC’s sets are consequently extended.
For instance, the permission set PRMS becomes
PRMS
B
= PRMS ∪ {BTG(p) : p ∈ PRMS}. We de-
fine PRMS
B
in such a way that it does not contain
nested BTG policies e.g., BTG(BTG(p)). We ex-
clude these policies as not useful: they suggest mul-
tiple “glasses” protecting a resource, so distorting the
meaning and delaying the BTG action. Relation PA
becomes PA
B
⊆ PRMS
B
× ROLES. The policy set,
which we still write π instead of π
B
to simplify the
notion, is also changed accordingly.
These definitions look trivial, but the way in which
BTG works is peculiar. First, a user asks for autho-
rization on p ∈ PRMS, not on BTG(p). Then, if he
is not authorized to p but is authorized to BTG(p), he
can break the glass; but he has to give consent, aware
that there will be consequences (Ferreira et al., 2009).
We show how this mechanism works but in a way
that differs from that proposed by Ferreira et al. (Fer-
reira et al., 2009). There is no BTG-state to remind
that a glass has been broken, and no next “requesters-
by” can take advantage of a glass already broken.
Function Auth
B
π
: USERS× PRMS → {ff,tt} be-
haves exactly as Auth
π
, and accepts a request for a
permission that is not a BTG. The auxiliary procedure
Auth
B
′
π
, which we report below, represents the core de-
cision making in the Auth
B
π
. The user’s decision of the
break-the-glass is collected somewhere else, and here
is given as an input parameter, a, which ranges on ‘y’
= “I want to break the glass” and ‘n’ = “I do not want
to break the glass”.
Auth
B
′
π
: USERS× PRMS× {y, n} → {ff,tt}
Auth
B
′
π
(u, p,a)
def
=











tt,if Auth
B
π
(u, p);
ff,if ¬Auth
B
π
(u, p) ∧(a = n);
(u,(BTG(p))) ∈ π
if ¬Auth
B
π
(u, p) ∧(a = y);
(1)
Informally u is authorized either when plays a role
that has p or when, despite not having p, has a role
that has BTG(p) and his answer is y.
Security Requirements. We have identified only
one security requirement for π. Advocating the view-
point of (Ferreira et al., 2009), break-the-glass is re-
served for exceptional situations and must not be pos-
sessed by default: so, having permission to BTG must
be stated in π. This requirement together with how (1)
works suggest that having p makes having BTG(p)
superfluous. But since from a security standpoint no
harm is done (simply, the third branch in (1) is never
executed) this last is more a consistency requirement
than a security one.
4.1 Running Example (Continued)
If we want to allow the situation illustrated in §3.3
using BTG only, we have to authorize Dr. Mario to
break the glass on reading. This must be set in π ac-
cording to our requirement. For readability, we write
op(obj) instead of (op,obj).
ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy
66

π = {(DrJohn,(read(blood test)));
(DrMario,(btg(read(blood
test))))}
This setting is however unsatisfactory. Dr. Mario has
the right to break-the-glass since the beginning. Al-
though the break-the-glass will be recorded (a deter-
rent for abuses) Dr. Mario can still misuse that right.
We need delegationfor letting Dr. Mario gain the right
to read dynamically and timely.
5 DELG
DELG in RBAC gives rise to extended models (e.g.,
see (Barka and Sandhu, 2000) (Barka and Sandhu,
2007) (Wang and Osborn, 2006)) that allowto transfer
permissions or roles. Here, we mainly describe dele-
gation of permissions: it permits a finer and more flex-
ible control over the accesses to data, which makes ac-
cess control more adaptable to the different situations
characterizing healthcare.
DELG can be a grant (the delegator maintains
the permission) or a transfer (the delegator loses
the permission). They are permissions in them-
selves: so if p = (op,ob) is a permission, D
g
v
(p) =
(grant
v
.op,ob) is the permission to grant to v per-
mission p, while D
t
v
(p) = (trans
v
.op,ob) is the per-
mission to transfer to v permission p. A delegation
can be revoked. RK
v
(p) = (revoke
v
.op,ob) is the
permission to revoke from v permission p.
Differently from BTG, nesting permissions, i.e.,
delegate a delegation, is meaningful here.
The RBAC’s elements change accordingly. Pre-
cisely: PRMS
D
= ∪
∞
i=0
PRMS
D
i
, where the various
PRMS
D
i
are defined as follows:























PRMS
D
0
= PRMS
PRMS
D
′
i+1
= {D
x
v
(p) : p ∈ PRMS
D
i
′
,
v ∈ USERS, x ∈ {g,t}}
PRMS
D
i+1
= PRMS
D
′
i+1
∪ {RK
v
(D
x
v
(p)) :
p ∈ PRMS
D
i
′
,v ∈ USERS, x ∈ {g,t}}
PRMS
D
is the language of all possible policies
(in an instance of RBAC only specific policies will
be considered) but it is not the richest possible: we
have excluded from it policies expressing delegation
of revoke. This is a simplification that we have made
to keep our description clear to show how the man-
agement of delegation works, but still rich enough to
compare its meaning with BTG. We consider to relax
this constrain in future work.
PA
D
is the extended relation PA that uses PRMS
D
.
The definition of policy set remains unchanged. We
continue to call the policy set π, instead of π
D
, to keep
the notation lightweight. The authorization function
Auth
D
π
: USERS × PRMS
D
→ {ff,tt} remains un-
changed, but the policy set needs to be updated after
any delegation/revocation.
In general, allowing delegation of roles (called
“referral” in (Becker, 2005)) and a dynamically
changing role hierarchy within a session may intro-
duce inconsistencies if used uncontrollably. This
calls for particular strategies of containment (e.g.,
see (Crampton and Khambhammettu, 2008)).
We can always refer to those strategies if we need
them, but for the sake of keeping our delegation
model simple we assume no dynamic change of roles.
We are motivated not to present the richest model del-
egation management but rather to discuss delegation
with respect to break-the-glass. However, even un-
der this simplified assumption one needs to control
what happens when permissions are dynamically as-
signed and then revoked. To trace this on the policy
set, we use a delegation history log, a solution that is
introduced and described in (Crampton and Khamb-
hammettu, 2008). After any delegation, the delega-
tion history log stores the delegator,the delegatee, and
the permissions temporarily acquired (by the delega-
tee) or lost (by the delegator in case of a transfer). It
changes again after a revocation. We also assume that
the right to revoke is gained dynamically as a conse-
quence of a delegation and kept until its use.
In the following we integrate directly the history
log into π. As π changes, we called it dynamic policy
set and we indicate it as π
′
. The dynamic policy set is
in fact a multiset, at first initialized to have the same
elements as π, then updated whenever a user delegates
or revokes a permission. Updating π
′
is the side-effect
of the exec procedure, which we assume to be the
procedure called to execute the operation authorized
by a policy. Here ⊔ is the multiset union:
exec(u,D
g
v
(p)): u grants permission p to v. Hence v
gains p and u gains the permission to revoke that
grant. π
′
::= π
′
⊔ {(v, p),(u, RK
v
(p))}.
exec(u,D
t
v
(p)): u transfers permission p to v. Hence
v gains p but u looses it and gains the permis-
sion to revoke. π
′
::= π
′
⊔ {(v, p),(u,RK
v
(p))} \
{(u, p)}.
exec(u,RK
v
(p)): u revokes p from v. Hence v loses
p and u recovers it but looses the permission to
revoke: π
′
::= π
′
⊔{(u, p)} \ {(v, p),(u,RK
v
(p))}.
The authorization procedure Auth
D
π
′
operates on
the dynamic policy (multi) set π
′
:
Auth
D
π
′
: USERS× PRMS
D
→ {ff,t t}
Comparing and Integrating Break-the-Glass and Delegation in Role-based Access Control for Healthcare
67

Auth
D
π
′
(u, p)
def
=
(
tt, if (u, p) ∈ π
′
ff, otherwise
(2)
Security Requirements. Doctors and patients
should not loose control over who is accessing
what data: we need to control that no one gains
permissions that are not meant to have.
For example, we may want to avoid that someone
could trigger a loop in the delegation chain as it hap-
pens when Auth
D
π
(u,D
u
(D
u
(p))) and ¬Auth
D
π
(u, p) or
when Auth
D
π
(u,D
v
(D
u
(p))) and ¬Auth
D
π
(u, p). The
first case suggests auto-assignment (we discuss thor-
oughly this case in §5.2; the second suggests u and v
collude to let u obtain a permission. We qualify such
circularities as vicious.
We can avoid vicious circularities by applying two
different modalities of control: one is exerted, let say,
endogenously to the policy set; the other one is ex-
erted, let say, exogenously to it. In the endogenous
control we limit the presence of polices in π that could
lead to vicious circularities. We express the control as
a security requirement, and a π compliant to it has no
policies that could lead to potentially insecure situa-
tions. This way of controlling abuses may constrain
the variety of situations we can model. In the exoge-
nous control we do not limit policies in π. However,
abuses are avoided by the enforcing mechanism that
needs to look for environmental pieces of information
to discern whether the request is an abuse or not be-
fore it can authorize the operation.
In this paper we opt for an endogenous control.
We constrain the policies in π to avoid that one can
delegate a permission s/he does not possess. For-
mally:
Requirement 1.
∀(u, p) ∈ π, Auth
D
π
(u,D
v
(p)) ⇒ Auth
D
π
(u, p)
Req 1 shapes how we can initialize the policy set
π: it cannot be that u has permission D
v
(p) but not
p. And, if p is a delegation (e.g., if p has the form
D
w
(p
′
)), then u has to hold p
′
too, and so recursively,
till the most innermost basic permission in p
′
.
The effect of Req 1 is that a permission p can be
passed even through many hoops but there is always
someone who holds p in π and stands at the root of a
chain of delegation for that p. This is expressed by a
Lemma (please recognize π
′
from π):
Lemma 1. Let π satisfy Req 1. Then ∀(u, p) ∈ π
′
,
Auth
D
π
′
(u, p) ⇒ either Auth
D
π
(u, p) or there exists v 6= u
that initiates the chain of delegation that ends with u
having p, and Auth
D
π
(v, p).
Proof. The non-obvious case is when Auth
D
π
′
(u, p)
and ¬Auth
D
π
(u, p). Here, u must have received p from
someone else, say w. Therefore there must have been
an instance of π
′
(not necessarily the current one),
such that Auth
D
π
′
(w,D
u
(p)). If Auth
D
π
(w,D
u
(p)) then
Auth
D
π
(w, p), for Req 1. Otherwise, w has received
that right from someone else, say z. This backtracking
eventually ends with a v that initiates the first delega-
tion and that holds that right of delegation, in π. Then
Auth
D
π
(v, p) must hold for Req 1.
Req 1 justifies a review of the procedure that up-
dates π
′
after a transfer: one should not be allowed
to delegate a permission p that one has transferred,
nor re-obtain it by creating vicious loops. This would
violate the spirit of the transfer. Thus the effect of
exec(u,D
t
v
(p)) on the current π
′
must be changed in
such a way to suspend u from starting a chain of del-
egation for p: this means removing all policies that
are nested delegation of p that u may have in π
′
; in
particular u looses D
t
v
(p). All such permissions will
be restored after the transfer is revoked.
Req 1 may impose a restriction on what scenarios
the model can handle. We cannot for example have
policies that give to the manager of a hospital the right
to delegate permission he does not have. Thus, if con-
fronted with an emergency when a responsible doctor
has left without having delegated a peer, the manager
cannot delegate whichever doctor is available at that
moment. However, relaxing Req 1 raises the need to
have what we called an exogenous control of abuses.
In our example, to understand whether the manager
is legitimate in delegating cannot be decided only on
the basis of his request; rather is the existence of a
situation of emergency that justifies his acting. This
condition can be checked in real-time before grant-
ing authorization, or a posteriori while auditing the
manager’s actions. There are a plethora of equally
good solutions to implement this control. However,
we have other reason to keep Req 1. It internalizes
the security concerns in the policy set itself and makes
it possible to compare the DELG and the BTG mod-
els without leaving any security implication out-of-
bound. This is essential in §5.2 where we discuss the
trust between delegator and delegatee only on the ba-
sis of the policies that bind them and without referring
to their context. Moreover, in §6 we will see that the
use of BTG will restore what seems lost by Req 1 in
terms of expressibility, but without the need of any
exogenous control.
5.1 Running Example (Continued)
The situation illustrated in §3.3 using DELG
is represented in the following policy set (we
write grant/trans fer(u, op(obj)) instead of
(grant
u
/tran sfer
u
.op,obj)):
ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy
68

π = {(DrJohn,(read(blood test)));
(DrJohn,(grant(Michel
(transfer(DrMario,(read(blood test)))))))}
First, let us stress that the decentralized paradigms
we advocate for healthcare suggests that is Dr. John
who initializes π. We imagine him setting the poli-
cies about the data he is managing. He is the one who
should have the right to initiate a chain of delegation
that sees Michel to transfer to Dr. Mario the right to
read. This use of delegation suggests that is discre-
tionary to Michel to decide when to transfer. She may
or may not follow Dr. John’s instructions on the mat-
ter. However, there is another way to define the same
situation by using auto-delegation.
π = {(DrJohn,(read(blood
test)));
(DrJohn,(grant(Michel,
(transfer(DrMario,
(grant(DrMario,(read(blood
test)))))))))}
This version is slightly different. Michel can
transfer Dr. Mario the right to auto-delegate reading.
How this setting differs from what is presented in
§4.1, where Dr. Mario was given the right to break-
the-glass and read, is discussed in the next section.
Note that assigning the right to read to Dr. Mario
would imply letting him have full read-control over
Rachel’s data despite her not being Dr. Mario’s pa-
tient.
5.2 Auto-delegation and BTG
For a user u, auto-delegation is a permission of the
form (u,D
g
u
(p)) that u is authorized to execute. Auto-
delegation can only be used as auto-grant, since auto-
transfer introduces the contradictory situation where
u gains and looses p at the same time.
Auto-delegation is not ruled out by Req 1, but it
constrains how u can get that permission. Namely, u
can possess auto-delegation of p because of (a) u has
already that right in π; (b) u has been delegated to
have it by delegation; however, in the chain of dele-
gation there is someone who, eventually, stholds p.
In case (a), Req 1 says that u must also hold p in
π, removing the need of auto-delegation.
In case (b), Lemma 1 says that the root of the del-
egation chain that ends in u must hold p in π.
That pointed out, we would like to understand
whether auto-delegation differs from BTG and, if it
does, what elements make them different. At a first
sight, some difference exists: having BTG in the ini-
tial policy set π is meaningful, whereas Req 1 sug-
gests this being superfluous for auto-delegation (case
(b) above). Deciding BTG requires an interaction
with the user, whereas auto-delegation does not. Ex-
cept these minor differences the two concepts look the
same.
Another way to shed light on the matter is by
asking what situations we can model with one that
we cannot with the other. Crampton and Mor-
riset (Crampton and Morisset, 2011) have shown that
auto-delegation can simulate break-the-glass. Auto-
delegation on p is authorized only if no one else with
at least the same role as the requester is logged in the
system. This use of auto-delegation supersedes BTG.
However, BTG has been explicitly introduced to
handle “exceptional situations”. BTG is meant to be
used parsimoniously and signals, in itself (i.e., en-
dogenously), an exception. Implementing BTG as
auto-delegation restrains auto-delegation for this ex-
ceptional usage only, even though auto-delegation
does not necessarily flag for any exceptional situa-
tions having occurred and although auto-delegation
could be used to model also different situations. In
fact, despite having the same consequences as auto-
delegation (i.e., that one circularly obtains a non-
possessed permission), BTG should not be used rou-
tinely. So, one way to inquire whether BTG is super-
fluous is by understanding whether auto-delegation
must be necessarily interpreted as an exceptional vi-
olation —as BTG is– or whether there are other uses
of auto-delegation than that which matches BTG. If
auto-delegation were necessarily interpreted as an ex-
ceptional violation, then auto-delegation would coin-
cide with BTG. Delegation would became the only
policy really needed and there would be nothing more
to discuss. But, if auto-delegation is not necessarily
interpreted as an exceptional violation, then we can
consider to keep BTG to handle violations, and free
auto-delegation for the other uses that this policy may
have.
We have an argument in favour of this latter sit-
uation. Req 1 suggests that auto-delegation can be
a transferable right (case (a) above) whereas nothing
indicates that it must be tolerated only under “excep-
tional situations”. Granting auto-delegation may be
done for other reasons. One of such reason is when
there is enough trust between delegator and delega-
tee to induce the delegator to let the delegatee auto-
delegate a right. For instance, only a doctor that trusts
her assistant delegates her the permission to auto-
grant reading a document. In fact, at least the RBAC
models described so far, when the assistant gains the
permission to read by auto-assignment, the doctor has
no power to revoke it. Only she can decide to auto-
revoke it. This use of auto-delegation suggests a de-
gree of trust that is higher than that occurring when
Comparing and Integrating Break-the-Glass and Delegation in Role-based Access Control for Healthcare
69

the doctor delegates directly the right to read, because
in this case the doctor retains the right to revoke the
delegated permission. At the same time, both situa-
tions suggest more trust then that in place when the
doctor grants a BTG on reading. Breaking-the-glass
is still a violation but it is tolerated, expected to be
infrequent, and occurring under well justified circum-
stances.
According to this interpretation, if we use auto-
delegation to implement BTG we miss the possibil-
ity to model the various situations just exemplified.
But if we let DELG co-exist with BTG then we are
left with two modalities to delegate auto-assigning a
right: one via BTG and the other via auto-delegation.
Even though any decision should be audited and the
reason of it questioned, in the first case the invoca-
tion of BTG is justified in the presence of exceptional
or urgent situations while the second does not require
that motivation; despite it can be question, it rests at
the delegatee’s discretion and responsibility. The re-
sulting RBAC looks richer in possibilities.
6 AN RBAC WITH BTG AND
DELG
Thus, we assume that BTG and DELG can co-exist
as different policies and we study a version of RBAC
that includes both. In so doing, we intend to verify
whether we obtain a different model than the one that
uses only delegation and where break-the-glass can
be simulated as auto-delegation. Our criterion of “be-
ing different” is defined in terms of having different
security requirements.
The language of this new RBAC’s policy is
PRMS
BD
= ∪
∞
i=0
PRMS
BD
i
, where the PRMS
BD
i
are it-
eratively defined as in Table 2. In PRMS
BD
there are
policies we consider useless: those expressing chains
of BTG, as we discussed in § 4; thoseexpressing loops
of auto-delegation, as discussed in § 5.2. Besides,
we consider useless those made of interleaved BTG
and DELG that express loops of auto-assignment e.g.,
(D
g
u
(BTG(D
g
u
(p)))) used for u.
The RBAC relations change accordingly with the
new permission set. PA
BD
is the relation PA that uses
PRMS
BD
. The new permissions can be subjected to
new obligations (but, as we have done so far, we do
not include them explicitly in the model).
The definitions of π and π
′
, which now operate on
the extended relations, remain the same, but updating
π
′
needs some discussion. In section §5 we pointed
out that, when u runs exec(u,D
t
v
(p)), i.e., a trans-
fer, u looses temporarily p and the right to delegate p.
This is still valid here at least for what concerns nested
delegations. Besides, u looses (possibly nested) dele-
gation of p that are conditioned by BTG: since u does
not possess p any more, it cannot delegate p even by
breaking-the-glass on delegation. The only exception
we may consider (but we have not a strong argument
for it) are delegations that would be allowed, if exe-
cuted, to let u re-obtain p. This seems to be in the
spirit of BTG, i.e., a tolerated but controlled viola-
tion whose effect is letting someone re-obtain p. It
seems an alternative way to revoke that right to a del-
egatee, but happening under the conditions dictated
by BTG. If this argument holds there is no reason to
suspend u from policies like e.g., BTG(D
g
v
(D
g
u
(p)) or
(D
g
v
(BTG(D
g
u
(p))) after u transfers p. The choice is
left to the discretion of the policy maker.
The definition of Auth
BD
π
and of Auth
BD
π
′
remains
unchanged but use the new π and π
′
. Formally:
Auth
BD
π
′
: USERS× PRMS
BD
→ {ff,tt}
Auth
BD
π
′
(u, p)
def
=
(
tt, if (u, p) ∈ π
′
ff, otherwise
Auth
BD
π
′
′
is the extended function requiring the answer
of the user on the break the glass policy:
Auth
BD
π
′
′
: USERS× PRMS
BD
∞
′
× {y,n} → {ff,tt}
Auth
BD
π
′
′
(u, p,a)
def
=











tt,if Auth
BD
π
′
(u, p);
ff,if ¬Auth
BD
π
′
(u, p) ∧(a = n);
Auth
BD
π
′
(u,(BTG(p))),
if ¬Auth
BD
π
′
(u, p) ∧(a = y);
PRMS
BD
is the set of all policies that do not start with
a BTG, that is PRMS
BD
= PRMS
BD
∞
′
\ ∪
∞
i=0
PRMS
BD
i
′′
.
Security Requirements. Since the model includes
DELG, Req 1 holds in this extension too. It remains
to state the requirements that emerge because of BTG
and DELG’s interleaving. The criterion we used to
identify the requirement is the same: to initialize π to
avoid that permissions appear from nowhere.
Requirement 2.
∀(u, p) ∈ π,
Auth
BD
π
(u,BTG(D
v
(p))) ⇒ Auth
BD
π
(u, p)
Req 2 says that, in π, when u is assigned the right
to break-the-glass and delegate a permission then u
must hold that permission. This is because BTG is
on delegation and when actually u violates the policy
and delegates p, u is the root of the chain and must
hold that permission. Req 2 avoids the creation of
permissions and preserves the BTG’s goal: obtaining
ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy
70

Table 2: The policy language combining BTG and DELG.











PRMS
BD
0
′
= PRMS
D
PRMS
BD
0
′′
= PRMS
B
PRMS
BD
0
= PRMS
BD
0
′
∪ PRMS
BD
0
′′













PRMS
BD
(i+1)
′
= {D(p) : p ∈ PRMS
BD
i
}
PRMS
BD
(i+1)
′′
= {BTG(p) : p ∈ PRMS
BD
i
′
}
PRMS
BD
i+1
= PRMS
BD
(i+1)
′
∪ PRMS
BD
(i+1)
′′
p must be occurring under a controlled violation of
the policy enforcement and not by vicious transfers
that short-cut BTG. This would happen, for example
if u where entitled, in π, to BTG(D
v
(D
u
(p)) without
holding p already. We stress that we are talking about
the initial policy set π; in the dynamic one, π
′
, such
situations can happen via a chain of delegations when
at the root there is someone who holds p.
This is indeed an interesting security property that
comes from Req 2 and Requirement 1. It is an exten-
sion of Lemma 1.
Lemma 2. Let π satisfy Reqs 1–2. ∀(u, p) ∈ π
′
such
that Auth
BD
π
′
(u, p) ∧ ¬Auth
BD
π
(u, p) then ∃w that initi-
ates the chain of delegation that ends with u having p,
and Auth
BD
π
(w, p).
Proof. (Concise). If u is not authorized to p from
some policy in π, it means that u has been delegated p
by someone. This someone either has the authoriza-
tion to delegate p or the possibility to break the glass
and delegate p. If he had those rights because of some
policy in π, then the thesis is proved for Req 2. If not,
he himself has been delegated. This creates a chain
that is finite, since users are finite in number and poli-
cies cannot be infinitely long. Let w be the one who
first starts to delegate. This can be because he has
the right to delegate or BTG on delegation; then, for
Req 2 or Req 1 w must have p.
We observe that, after integrating BTG with
DELG, our security requirementis no more restrictive
in terms of expressiveness. The situation in § 5 see-
ing an hospital manager delegating to whichever doc-
tor was available in case of an emergency (which was
hard to model using delegation in a policy set compli-
ant with Req 1) can be now easily modelled by letting
the manager having BTG right on delegation.
In this extended model there is another desirable
property:
Property 1.
∀(u, p) ∈ π, Auth
BD
π
(u,D
v
(p)),v 6= u⇒
Auth
BD
π
(u,D
v
(BTG(p)))
Property 1 suggests that whoever has permission
to delegate p can delegate less permissive permissions
than p, i.e., BTG on p and auto-delegation on p. How-
ever, this property has no consequences on the secu-
rity of the model as Reqs 1 and 2 have. We do not
impose it as mandatory, but we leave to the discretion
of the policy maker to following it in order to lead
to more flexible decisions. In healthcare this is often
desirable for decisions are often taken on the basis of
need-to-know accesses.
6.1 Running Example (Epilogue)
We can now give a more satisfactory implementation
of policies for the scenario described in §3.3. Dr. John
delegates his assistant to transfer the right to read to
Dr. Mario. However, since Dr. John does not want
Michel to abuse this right but only use it as an ex-
ceptional measure, he imposes a BTG of that right in-
stead of a full permission. The risk of abuses should
be more deterred than in the previous example using
delegation only. As soon as Dr. John is back, he can
revoke the assigned permissions. Note that Dr. John
could have decided to let Michel transfer to Dr. Mario
the permission to auto-delegate the reading instead
of the permission to read directly. This requires an
higher level of trust between the doctors.
The policies are set around Dr. John. He can start
the chain of delegation before he leaves. Below, we
write more compactly op(obj) instead of (op,obj),
and grant(u,op(obj)) instead of (grant
u
.op,obj)):
π = {(DrJohn,(read(blood
test)));
(DrJohn,(grant(Michel,(btg(transfer
(DrMario,(read(blood test))))))))}
Such set, however, violates Req 1. In order to
grant that right to his assistant, Dr. John must have the
permission to BTG and transfer his colleague as well.
This triggers also Req 2 suggesting that Dr. John must
have the right to read himself, which he already has.
A compliant policy set is therefore the following:
π = {(DrJohn,(read(blood
test)));
(DrJohn,(grant(Michel,(btg(transfer
(DrMario,(read(blood
test))))))));
(DrJohn,(btg(transfer
(DrMario,(read(blood test))))))}
Then it comes the moment when Dr. John leaves. He
grants his assistant with the necessary right to act on
his behalf. This will change dynamically the policy
set as follows:
Comparing and Integrating Break-the-Glass and Delegation in Role-based Access Control for Healthcare
71

π
′
= π ∪ {(DrJohn,revoke
(Michel,(btg(transfer,
(DrMario,(read,blood test))))));
(Michel,(btg(transfer
(DrMario,(read,blood test)))))}
Michel does not necessarily have the right to read,
i.e., Req 2 does not apply here. But this is fine because
Michel has received the right to break-the-glass and
transfer from Dr. John who is at the root of the dele-
gation chain. Then it comes the time when Dr. Mario
needs accessing Rachel’s health records. Michel can
break the glass and transfer to him the right to read
Rachel’s blood test. When Michel breaks the glass
and transfers the policy set becomes:
π
′
= π
′
∪ {(DrMario,(read,blood
test));
(Michel,(revoke(DrMario,(read,blood
test))))}
Dr. Mario has now the right to read until Michel re-
vokes it.
7 CONCLUSIONS AND FUTURE
WORK
In healthcare, accessing medical data is particularly
critical because most of the records contain sensitive
information. This justifies a strict control of accesses
to the data. However, the enforcement should be flex-
ible to work in circumstances of emergency, which
stretch the applications of the access control rules.
Features such as break-the-glass and delegation
have been introduced rightly to cope with such situa-
tions. They work best in a decentralized architecture
without a central authority that distributes accesses
and takes decisions, because these tasks are usually
left to healthcare practitioners who face often unpre-
dictable situations.
So far, no RBAC model combines break-the-glass
and delegation. It is even unclear whether these
two permissions are independent. Auto-delegation
has been shown to approximate a break-the-glass be-
haviour, but the question whether the two permissions
are really both necessary or not has not been stated not
answered. We have deepened the subject and given an
answer to it. We showed that there is an interpretation
of auto-delegation which can coexist with break-the-
glass without overriding it but rather making the re-
sulting access control model richer. In the domain of
healthcare access control this coexistence is justified
and we provided logical arguments in its support.
As a result we proposed an access control model
of the RBAC family that integrates break-the-glass
and delegation. We defined the authorization func-
tion and the tools to keep the policy set updated after
a delegation (a grant or a transfer) or/and a break-the-
glass action. We studied what security requirements
a policy set that handles both permissions must have.
These requirements can be used with a policy checker
to help policy makers —doctors and patients— write
secure-by-design policies.
The functionalities introduced in this paper (i.e.,
the authorization function and the security require-
ments) are meant to be implemented and integrated
into an access control system. The high-level ar-
chitecture we envision is depicted in Fig. 1. The
authorization functions can be integrated into the
enforcement point (Authorization/Enforcement), to-
gether with the procedures that keep π updated as we
explained in §6. Our requirements can be instead im-
plemented as a front-end (Policy Checker) that helps
a policy maker —a patient or a doctor— to write se-
curity policies on the data s/he owns or is a guardian
for. This front-end can be employed in two comple-
mentary ways: (1) as a policy checker that evaluates
whether an already defined policy set contains poten-
tial vicious circularities; (2) as a policy helper that
suggests in real time the missing policies that make
the policy set compliant with the requirements. In this
way, the policy maker can concentrate on designing
the core permissions, according to the access control
high-level strategy s/he is implementing, while hav-
ing the subsidiary security-compliant policies set au-
tomatically.
As proof-of-concept we have prototyped the pol-
icy checker and the authorization function in Ocaml
(http://ocaml.org) and used it to validate our require-
ments against samples of policy sets
1
. One of them
has been reported here as a running example.
This work has limitations that we intend to address
in the future. First, we simplified considerably the
delegation model by assuming no delegation of roles
and no delegation of revocation. In the scope of this
paper’s goal this simplification was justified to keep
focus on comparing delegation and break-the-glass as
policies. Considering a fully fledged management of
delegation would have complicated the section on del-
egation with no benefit for the part where we compare
the two types of policies. However, after we proved
that delegation and break-the-glass can coexist, con-
sidering a complete treatment of delegation becomes
justifiable. Adding delegation of roles it is mainly a
technical problem, since we can adopt standard solu-
tions from the literature (e.g., (Zhang et al., 2003)).
Adding delegation of revocation should not require
much effort, except restoring a fully informative del-
1
The Ocaml code is available on request.
ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy
72

Policy CheckerPolicy Maker Policy Set π
Authorization
Enforcement
Data
Figure 1: Our access control system and our requirements in support to a policy maker.
egation history log (separated and not integrated in π
as we did here) to be able to return a permission p to
the original owner/delegator when it is revoked from
the delegatee by a third-party.
ACKNOWLEDGEMENT
We are grateful to several anonymous reviewers. In
different rounds of evaluation, their positive critics
helped us to improve our arguments and the relevance
of our contribution.
REFERENCES
Barka, E. and Sandhu, R. (2000). Framework for role-based
delegation models. In Proc. of 6th Ann. Conf. on
Computer Security Applications (ACSAC’00), pages
168–176.
Barka, E. and Sandhu, R. (2007). Framework for Agent-
based Role Delegation. In Proc. of the IEEE Int.
Conf. on Communications (ICC’07, pages 1361–1367
Becker, M. Y. (2005). A Formal Security Policy for an NHS
Electronic Health Record Service. Technical Report
UCAM-CL-TR-628, University of Cambridge.
Brucker, A. D. and Petritsch, H. (2009). Extending Access
Control Models with Break-glass. In Proc. of the 14th
ACM Symposium on Access Control Models and Tech-
nologies (SACMNAT ’09), pages 197–206. ACM.
Crampton, J. and Khambhammettu, H. (2008). Delegation
in role-based access control. Int. J. of Information Se-
curity, 7(1):123–136.
Crampton, J. and Morisset, C. (2011). An auto-delegation
mechanism for access control systems. In Proc. of Se-
curity and Trust Management (STM), volume 6710 of
LNCS, pages 1–16. Springer Berlin Heidelberg.
Ferreira, A., Chadwick, D., Farinha, P., Correia, R., Zao,
G., Chilro, R., and Antunes, L. (2009). How to Se-
curely Break into RBAC: The BTG-RBAC Model. In
Proc. of 5th Ann. Conf. on Computer Security Appli-
cations Conference (ACSAC’09), pages 23–31.
Ferreira, A., Cruz-Correia, R., Antunes, L., and Chadwick,
D. (2007). Access control: how can it improve pa-
tients’healthcare? In Medical and Care Compunetics,
volume 127 of Studies in Health Technology and In-
formatics, pages 65–76.
Ferreira, A., Cruz-Correia, R., Antunes, L., Farinha,
P., Oliveira-Palhares, E., Chadwick, D., and Costa-
Pereira, A. (2006). How to break access control in a
controlled manner. In Proc. of 19th IEEE Int. Symp. on
Computer-Based Medical Systems (CBMS), pages
847–854.
Hasebe, K. and Mabuchi, M. (2010). Capability-
role-based delegation in workflow systems. In
Proc. of IEEE/IFIP 8th Int. Conf. on Embedded and
Ubiquitous Computing (EUC 10), pages 711–717.
ISO/TS (2009). ISO/TS 13606-4: Health informatics - elec-
tronic health record communication - part 4: Security.
Krautsevich, L., Martinelli, F., Morisset, C., and Yaut-
siukhin, A. (2012). Risk-Based Auto-delegation for
Probabilistic Availability. In Data Privacy Manage-
ment and Autonomous Spontaneus Security, volume
7122 of LNCS, pages 206–220. Springer Berlin Hei-
delberg.
Li, M. and Wang, H. (2008). ABDM: An extended flex-
ible delegation model in RBAC. In Proc. of the 8th
Int. Conf. on Computer and Information Technology
(CIT 2008), pages 390–395.
Maw, H., Xiao, H., Christianson, B., and Malcolm, J.
(2014). An evaluation of break-the-glass access con-
trol model for medical data in wireless sensor net-
works. In Proc. of IEEE 16th Int. Conf. on e-Health
Networking, Applications and Services (Healthcom),
pages 130–135.
Rajesh, K. and Nayak, A. (2012). Modified BTG-RBAC
model for SaaS. In Cloud Computing Technologies,
Applications and Management (ICCCTAM), 2012 In-
ternational Conference on, pages 77–81.
Rissanen, E., Firozabadi, B., and Sergot, M. (2006). To-
wards a Mechanism for Discretionary Overriding of
Access Control. In Security Protocols, volume 3957
of LNCS, pages 312–319. Springer Berlin Heidelberg.
Rostad, L. and Edsberg, O. (2006). A study of access con-
trol requirements for healthcare systems based on au-
dit trails from access logs. In Proc. of the 22nd Annual
Computer Security Applications Conference (ACSAC
’06), pages 175–186.
Sandhu, R., Coyne, E., Feinstein, H., and Youman, C.
(1996). Role-based access control models. Computer,
29(2):38–47.
Wainer, J. (2005). A fine-grained, controllable, user-to-
user delegation method in RBAC. In Proc. of 10th
ACM Symp. on Access Control Models and Technolo-
gies (SACMAT ’05), pages 59–66. ACM Press.
Wang, H. and Osborn, S. L. (2006). Delegation in the
role graph model. In Proc. of 11st ACM Symp. on
Access Control Models and Technologies (SACMAT
’06), pages 91–100. ACM.
Zhang, X., Oh, S., and Sandhu, R. (2003). PBDM: A Flex-
ible Delegation Model in RBAC. In Proc. of the 8th
ACM Symp. on Access Control Models and Technolo-
gies (SACMAT ’03), pages 149–157, New York, NY,
USA. ACM.
Zhao, G., Chadwick, D., and Otenko, S. (2007). Obligations
for Role Based Access Control. In Proc. of the 21st
Int. Conf. on Advanced Information Networking and
Applications Workshop (AINAW’07), volume 1, pages
424–431.
Comparing and Integrating Break-the-Glass and Delegation in Role-based Access Control for Healthcare
73