C2RBAC: An Extended Capability-Role-Based Access Control with
Context Awareness for Dynamic Environments
Mitsuhiro Mabuchi
1
and Koji Hasebe
2
1
Toyota Motor Corporation, Japan
2
Department of Computer Science, University of Tsukuba, Japan
Keywords:
Access Control, Context-aware, Delegation, Capability, RBAC.
Abstract:
Various working styles, such as remote work, have become more common instead of working in one of-
fice. Moreover, to accelerate the development of new technologies, collaborations among multiple companies
are increasing. Thus, most development projects are operating in dynamic environments, for example, dy-
namically changing teams, working from anywhere and at any time. To ensure security in such dynamic
environments while maintaining efficiency, flexible and scalable access control is necessary. We previously
proposed capability-role-based access control (CRBAC) that allows users to create capabilities for delegating
authority across various domains without an administrator’s operation. However, in dynamic environments,
a finer control is required based on where and when the authority is delegated or executed. In this paper,
we propose an access control model called context-aware CRBAC (C2RBAC). This model is an extension of
CRBAC obtained by introducing a mechanism of context-based restrictions on various operations regarding
the delegation of authority by capabilities, such as time, place, and device. In this paper, we present a formal
definition of C2RBAC and demonstrate its effectiveness using an example of collaborative development.
1 INTRODUCTION
Various working styles, such as remote work, have
become more common instead of working in one of-
fice. In particular, because remote work is spread-
ing rapidly due to the COVID-19 pandemic, the use
of resources (servers and databases) from unexpected
places, such as public spaces, is increasing. More-
over, to accelerate the development of new technolo-
gies, collaborations among multiple companies are
increasing, for example, the collaboration of a com-
pany with data analysis skills and a company having
big data.
Thus, most development projects are operated in
dynamic environments because the team is assumed
to be dynamically organized across companies, and
the working style also changes dynamically, such as
places, times, and devices depending on situations.
Flexible and scalable access control is paramount to
ensure security in such dynamic environments while
maintaining efficiency. However, configuring access
control by administrators may consume time and is
inflexible if the team changes frequently. Manually
assigning authority to users in other domains makes
managing the system even more challenging. Further-
more, confidential data such as personal information
must be protected from unexpected use by access con-
trol.
We previously proposed capability-role-based ac-
cess control (CRBAC) (Hasebe et al., 2010) that is
an extension of role-based access control (RBAC)
(Sandhu et al., 1996) with capability-based access
control (CBAC) (Snyder, 1981), (Levy, 1984). CR-
BAC allows users to create capabilities from their
capabilities for delegating authority across domains
without an administrator’s operation. However, a
finer control is required in dynamic environments de-
pending on where and when the authority is delegated
or executed. Because CRBAC cannot set any limita-
tion by contexts associated with environments, users
having access to a customer information database can
obtain sensitive information from that database.
To realize such capability management, we pro-
pose an access control model called context-aware
CRBAC (C2RBAC). This model is an extended CR-
BAC model with context-awareness. C2RBAC can
impose context-based restrictions on various opera-
tions related to the delegation of authority by ca-
pabilities, such as time, place, and device. The
context-based restrictions can prevent potential issues
in dynamic environments, for example, an unexpected
Mabuchi, M. and Hasebe, K.
C2RBAC: An Extended Capability-Role-Based Access Control with Context Awareness for Dynamic Environments.
DOI: 10.5220/0010601508190826
In Proceedings of the 18th International Conference on Security and Cryptography (SECRYPT 2021), pages 819-826
ISBN: 978-989-758-524-1
Copyright
c
 2021 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
819

propagation of capability and the use of capability
from an unexpected place or time. The contexts com-
prise surrounding environment information of users,
such as place, time, and device, whereas the con-
straints are attributes of capabilities or roles, such as
the number of uses and expiration date. The con-
texts can be evaluated with rules attached to capa-
bilities whenever users use a capability. In this pa-
per, we formally define the C2RBAC model as the
basic C2RBAC0 model and describe model families
C2RBAC1, C2RBAC2, and C2RBAC3. Furthermore,
we demonstrate the effectiveness of C2RBAC using
an example of collaborative development.
The rest of this paper is organized as follows. Sec-
tion 2 presents related work and comparison results.
Section 3 introduces the C2RBAC model. Section 4
demonstrates the application of C2RBAC considering
a plausible case of collaborative development as a dy-
namic environment. Finally, Section 5 concludes this
study and presents future work.
2 RELATED WORK
RBAC (Sandhu et al., 1996) is widely used as a model
for hierarchical and efficient access control in an or-
ganization or a system. It assigns a preset role that is a
set of permissions to appropriate users by authenticat-
ing their identities. The permission-based delegation
model (Zhang et al., 2003) is an extension of RBAC
to realize role delegation among users in a single do-
main. These enable fine-grained access control for a
well-organized company or system.
Numerous context-aware applications (Baldauf
et al., 2007) have been proposed for adapting dynamic
environments, such as the Internet of Things. In
particular, some applications extended RBAC to de-
fine new access control models to realize fine-grained
and well-organized access control in dynamic envi-
ronments. Context-aware RBAC (Kulkarni and Tri-
pathi, 2008) supports dynamic environments, such as
place and time, by personalizing user access privi-
leges based on the context information collected by
the context management layer. Contex-role based
access control (Park et al., 2006) based on RBAC
was proposed by introducing context-role to adapt
to dynamic environments. Moreover, all environ-
ment roles were created and managed by adminis-
trators; therefore, this model could not yield flexi-
ble and scalable access control in expected dynamic
environments. Schefer-Wenzl et al. (Schefer-Wenzl
and Strembeck, 2013) proposed a model that supports
dynamic environments by extending process-related
RBAC (Strembeck and Mendling, 2011) with context
and setting restrictions by context when executing a
certain task. Covington et al. (Covington et al., 2001)
proposed a model that combines newly defined envi-
ronment roles assigned to users based on context in-
formation with existing subject roles assigned to users
based on user identity.
Another extension of RBAC, Rule-based RBAC
(RB-RBAC) (Al-Kahtani and Sandhu, 2002), was
proposed based on attribute information to address ac-
cess control in dynamic environments. As a result of
comparing a user’s attribute with role allocation rules,
PB-RBAC assigns a specific role to that user. In addi-
tion, when the attribute changes because of environ-
mental changes, RB-RBAC performs the comparison
of new attributes and rules to assign an appropriate
role. In attribute-based access control (ABAC) (Jin
et al., 2012), the attribute is defined as a function that
takes an entity as input and outputs a value within
a specific range. ABAC realizes fine-grained access
control by adding attributes to all users, subjects, and
objects. Our previous model, CRBAC (Hasebe et al.,
2010), is an extension of RBAC with CBAC that en-
ables flexible cross-domain access authority delega-
tion. In CRBAC, users can create new capabilities
from capabilities or roles assigned to them for dele-
gating authority without any operation by the admin-
istrator.
We also proposed workflow-aware CRBAC (W-
CRBAC) (Hasebe and Mabuchi, 2010) for applying
the workflow system to CRBAC. W-CRBAC supports
the workflow system to use a task transferable along
with permissions by mapping a task to both a capabil-
ity and a role.
We evaluate C2RBAC and other access control
models described above in terms of the following
eight items.
(1) Adding new members (or assigning authority to
a user who has not been registered to a system)
without an administrator’s operation
(2) Delegating authority to users in the same domain
without an administrator’s operation
(3) Revoking delegated authority from users in the
same domain without an administrator’s operation
(4) Delegating authority to users in different domains
without an administrator’s operation
(5) Revoking delegated authority from users in differ-
ent domains without an administrator’s operation
(6) Preventing unexpected authority propagation
(7) Restricting authority management by a contextual
information
(8) Traceability of authority propagation
SECRYPT 2021 - 18th International Conference on Security and Cryptography
820

Table 1: A comparison table of access control models which adapted to dynamic environments.
RBAC
(Sandhu et al., 1996)
PBDM
(Zhang et al., 2003)
Context-aware RBACs
(Kulkarni and Tripathi, 2008),
(Park et al., 2006),
(Schefer-Wenzl and Strembeck, 2013),
(Covington et al., 2001)
RB-RBAC
(Al-Kahtani and Sandhu, 2002)
ABAC
(Jin et al., 2012)
CRBAC
(Hasebe et al., 2010)
W-CRBAC
(Hasebe and Mabuchi, 2010)
C2RBAC
our new model
(1) X X
(2) X X X X X
(3) X X X X X
(4) X X
(5) X X
(6) X X X partly X
(7) X X X
(8) X X X X X
CRBAC, W-CRBAC, and C2RBAC can realize
(1), (4), and (5) by exploiting the characteristics of
CBAC. All models described above can realize (2),
(3), and (8). However, CRBAC and W-CRBAC pre-
vent capability propagation by constraints, such as the
number of delegations and expiration date; they can-
not perfectly realize (6) if there is a malicious user
because of capability flexibility. Therefore, C2RBAC
uses context restrictions to prevent them. Regard-
ing (7), context-aware models, RB-RBAC, ABAC,
and C2RBAC, can support dynamic environments.
C2RBAC supports all items to achieve secure, flex-
ible, and scalable access control for dynamic environ-
ments.
3 C2RBAC
This section gives a formal definition of our pro-
posed Context-Aware Capability Role Based Access
Control (C2RBAC). C2RBAC is a family consist-
ing of four models named C2RBAC0 to C2RBAC3.
C2RBAC0 is a base model. C2RBAC1 and 2 are ex-
tensions of C2RBAC0 by introducing role hierarchy
and restrictions, respectively. Here, context is for-
mally represented as a set of variables ranging over
states in the system, such as the current time, IP ad-
dress of a user’s terminal. Context can restrict on each
operation of the delegation of authority, i.e. creation,
transfer, execution of authority, and revocation of ca-
pablity.
Below, Section 3.1 defines the base model. Sec-
tion 3.2 gives the definition of delegation of authority
with capability in this model as a state transition of
the system. Finally, Section 3.3 describes the exten-
sion of the base model. The application of the model
defined above to an example will be shown in the next
section.
3.1 C2RBAC0
The C2RBAC0 is the base model of the C2RBAC
family. The formal definition is the following. (See
also Figure 1 for a graphical presentation of the fam-
ily of C2RBAC models. In this figure, the definition
of the expression “rh
i
”, which refers to the role hier-
archy, is described in the definition of C2RBAC2 in
Section 3.3.)
Definition 1 (C2RBAC0). The C2RBAC0 model has
the following basic components. (Here, for a set X,
the notation P (X ) denotes the powerset of X.)
• Sub, Dom: the sets of subjects and domains, re-
spectively.
• Role
i
, Per
i
, Ses
i
, Cap
i
: the sets of roles, permis-
sions, sessions, and capabilities in the i-th domain
for each i ∈ Dom, respectively. Here, Per
i
may
contain a special kind of permission, called cre-
ation of capabilities, denoted by create.
• S = S
1
× · · · × S
k
: the set of all possible states of
the system. Here, a state is a snapshot of the sys-
tem described by the values of the variables of the
system at a given moment. In the following, a
state of the entire system si called a global state,
while a state of a part of the system (especially in
a domain) is called a local state.
• Cxt = C xt
1
× ·· · × Cxt
n
: the set of all possible
global states (or called contexts), where Cxt
i
for
each i = 1,. . . ,n is the set of all possible local
states in the i-th domain. That is, Cxt
i
= Cxt
1
i
×
··· × Cxt
h
i
where Cxt
j
i
= S
0
j
for all j = 1, . .., h
with j
0
= 1, . . . ,k. Here, various kinds of states
can be regarded as contexts. For example, the
time (from 0 to 23) and the user’s location (L
1
,
L
2
, and L
3
) when a session is activated in Do-
main 1 are considered as contexts, the set Cxt
1
is
Cxt
1
1
×Cxt
2
1
with Cxt
1
1
= {0,1, . . . , 23} and Cxt
2
1
=
{L
1
,L
2
,L
3
}. As a notational convention, to indi-
cate a global or local state of the system (i.e., an
C2RBAC: An Extended Capability-Role-Based Access Control with Context Awareness for Dynamic Environments
821

Sub
Usr
1
Usr
i
Usr
n
. . .
Cap
i
Role
i
Ses
i
Per
i
Cxt
i
UCA
j, i
URA
i
ses_u
i
ses_c
i
ses_r
i
rh
i
RPA
i
CPA
i
Model of the 1st domain
Model of the n-th domain
CRA
i
Usr
j
. . .
ses_cxt
i
SCA
i
SRA
i
Figure 1: The family of C2RBAC models.
element of set Cxt or Cxt
i
), we often use σ or σ
i
.
In addition to the above components, the follow-
ing functions and relations are defined for each i ∈
Dom:
• usr : Dom → P (Sub), a function that determines
the set of users in the i-th domain for each i ∈
Dom. We also use the notation Usr
i
to de-
note usr(i). Hereafter, we assume that Sub =
S
i∈Dom
Usr
i
with Usr
i
∩ Usr
j
=
/
0 for any i 6= j.
• ses u
i
: Ses
i
→ Usr
i
, a function mapping each ses-
sion in the i-th domain to the user who establishes
it.
• ses r
i
: Ses
i
→ P (Role
i
), a function mapping each
session in the i-th domain to a set of roles that is
activated by this session.
• ses c
i
: Ses
i
→ P (Cap
i
), a function mapping each
session in the i-th domain to a set of capabilities.
• ses cxt
i
: Ses
i
→ Cxt
i
, a function mapping each
session in the i-th domain to the local state when
the session is established.
• URA
i
⊆ Usr
i
× Role
i
, a many-to-many user-to-
role assignment relation.
• RPA
i
⊆ Role
i
× Per
i
, a many-to-many role-to-
permission assignment relation.
• UCA
j,i
: Usr
j
→ P (Cap
i
), a function mapping
each user in the j-th domain to a set of capabil-
ities.
• CRA
i
⊆ Cap
i
×Role
i
, a many-to-many capability-
to-role assignment relation.
• CPA
i
⊆ Cap
i
× Per
i
, a many-to-many capability-
to-permission assignment relation.
• SRA
i
⊆ Cxt
i
× Role
i
, a many-to-many context-to-
role assignment relation.
• SCA
i
⊆ Cxt
i
×Cap
i
, a many-to-many context-to-
capability assignment relation.
These components satisfy the following condi-
tions:
(C0-1) ses r
i
(s) ⊆ {r | hses u
i
(s),r i ∈ U RA
i
}, means
any role activated by a session is one that is as-
signed to the user who establishes the session.
(C0-2) ses r
i
(s) ⊆ {r | hses cxt
i
(s),r i ∈ SRA
i
}.
(C0-3) Session s has the permissions
S
r∈ses r
i
(s)
{p|hr, pi ∈ RPA
i
}.
(C0-4) ses c
i
(s) ⊆ {c | hses u
i
(s),ci ∈ UCA
i
}, means
any capability activated by a session is owned by
the user who establishes the session.
(C0-5) ses c
i
(s) ⊆ {c | hses cxt
i
,ci ∈ SCA
i
}.
(C0-6) For any r ∈ Role
i
and c ∈ Cap
i
, if hc, ri ∈
CRA
i
then session s has the permissions that
are determined by (C0-2) above, otherwise
(i.e., hc, ri 6∈ CRA
i
) then s has the permissions
S
c∈ses c
i
(s)
{p | hc, pi ∈ CPA
i
}.
The C2RBAC0 is a pure extension of the CRBAC
model, which was introduced by our previous work
based on the RBAC96 model. Here, the components
Contexts
i
, ses cxt
i
, S RA
i
, and SCA
i
are the extended
parts from CRBAC, each of which plays the follow-
ing roles: Context
i
denotes the set of all possible local
states in the i-th domain; function ses cxt
i
determines
the context when each session is established; relations
SRA
i
and SCA
i
determine the set of roles and capabil-
ities that can be activated in each state, respectively.
3.2 Delegation of Authority
Similar to the CRBAC proposed in our previous study,
various types of delegations are provided in C2RBAC.
As described in (Hasebe et al., 2010), the delegation
using capability transfer is modeled as the sequential
composition of the following three basic operations.
(Step 1) Creation. A user creates a new capability.
SECRYPT 2021 - 18th International Conference on Security and Cryptography
822

(Step 2) Assignment. A user assigns authority to the
capability.
(Step 3) Transfer. A user sends the capability created
in the previous steps to another user.
For each of the first two steps, we can consider the
following two cases. For Step 1, there are two cases
in which the authority to create a new capability is
based on the (1) role or (2) capability of the user who
created the capability. For Step 2, there are two cases
in which the authority to be delegated assigned to the
created capability is either (3) a role or (4) a capa-
bility. According these cases, we classify delegations
into four types D1–D4 as shown in Table 2.
Table 2: Types of Delegations.
Assign
Create from
(1)
Role
(2)
Capability
(3) Role D1 D3
(4) Capability D2 D4
We define the delegation of authority as the state
transitions in the model.
Definition 2 (Basic operations for delegation). The
basic operations for delegation (i.e., creation, assign-
ment, and transfer) are defined by the following rules
of state transitions for a model. Here, CH
i
(called
creation history) is a set of quadruple of the form
hu,σ, x, ci with u ∈ Usr
i
, σ ∈ S, x ∈ Role
i
∪Cap
i
, and
c ∈ Cap
i
. Intuitively, an element hu, σ, x, ci in CH
i
means that user u creates a capability c in state σ by
executing his/her authority assigned to the role or ca-
pability x. Thus, CH
i
indicates the history of creations
of capabilities in the i-th domain.
Creation Rule: Let σ be a state such that hu, σ, x,ci ∈
CH
i
.
(1) If r ∈ Role
i
with hu, ri ∈URA
i
, hr, createi ∈ RPA
i
,
and hσ, ri ∈ SRA
i
, then this rule can be applied to
σ and defines new state σ
0
by replacing Cap
i
and
CH
i
in σ with Cap
0
i
and CH
0
i
, respectively, such
that:
• Cap
0
i
:= Cap
i
∪ {c
0
} where c
0
6∈ Cap
i
;
• CH
0
i
:= CH
i
∪ {hu,σ, r,c
0
i}.
(2) If hu, ci ∈ UCA
i
, hc, createi ∈ CPA
i
, and hσ, ci ∈
SCA
i
, then this rule can be applied to σ and defines
new state σ
0
by replacing Cap
i
and CH
i
in σ with
Cap
0
i
and CH
0
i
, respectively, such that:
• Cap
0
i
:= Cap
i
∪ {c
0
} where c
0
6∈ Cap
i
;
• CH
0
i
:= CT
i
∪ {hu,σ, c, c
0
i}.
The state transitions of these types are denoted by
σ
cre(u,r,c
0
)
σ
0
(for Case (1)) and σ
cre(u,c,c
0
)
σ
0
(for Case
(2)), respectively, and we can say “capability c
0
is cre-
ated by user u from his role r (from his capability c,
resp.)”
Assignment Rule: Let σ be a state, u ∈ Usr
i
, and c
0
(∈ Cap
i
) is created by u.
(3) If R
0
⊇ R ⊇ Role
i
in σ such that hu, ri ∈ URA
i
for any r ∈ R, then this rule can be applied to σ
and defines new state σ
0
by replacing CRA
i
in σ
with CRA
0
i
:= CRA
i
∪{hc
0
,ri | r ∈ R
0
} and SRA
0
i
:=
SRA
i
∪ {hσ,r i | σ ∈ S, r ∈ R
0
}.
(4) If P ⊇ Per
i
in S, then this rule can be applied to
σ and defines new state σ
0
by replacing CPA
i
in S
with CPA
0
i
:= CPA
i
∪{hc
0
, pi | p ∈ P} and SCA
0
i
:=
SCA
i
∪ {hσ,c
0
i | σ ∈ S}.
State transitions of these types are denoted by
σ
asg(R
0
,c
0
)
σ
0
(for Case (3)) and σ
asg(P
0
,c
0
)
σ
0
(for Case
(4)), respectively, and we can say “roles R
0
(permis-
sions P
0
, resp.) is assigned to capability c”.
Transfer Rule: Let σ be a state in which u ∈ Usr
i
,
u
0
∈ Usr
j
, c
0
∈ Cap
i
, and c
0
is created by u (where
i and j may be the same domain number). Then
this rule can be applied to σ and defines new state
σ
0
by replacing UCA
i, j
in σ with UCA
0
i, j
:= UCA
i, j
∪
{hu
0
,c
0
i} . State transitions of this type are denoted by
σ
trans(u,u
0
,c
0
)
σ
0
and we can say “capability c
0
is trans-
ferred from user u to the other user u
0
”. In particular,
such transfer is called a cross-domain transfer if i 6= j.
By combining these basic operations, we define
the delegations of types (D1) to (D4).
Definition 3 (Delegation). The delegations of types
(D1) to (D4) are sequential compositions of basic op-
erations Creation, Assignment, and Transfer as fol-
lows (where “;” is used to denote the sequential-
composition operator):
(D1) σ
cre(u,c
0
,r)
;
asg(R
0
,c
0
)
;
trans(u,u
0
,c
0
)
σ
0
.
(D2) σ
cre(u,c
0
,r)
;
asg(P
0
,c
0
)
;
trans(u,u
0
,c
0
)
σ
0
.
(D3) σ
cre(u,c
0
,c)
;
asg(R
0
,c
0
)
;
trans(u,u
0
,c
0
)
σ
0
.
(D4) σ
cre(u,c
0
,c)
;
asg(P
0
,c
0
)
;
trans(u,u
0
,c
0
)
σ
0
.
For readability, we also use the following notations to
denote delegations of these types:
(D1) σ
D1(u,u
0
,c
0
,r,R
0
)
σ
0
.
(D2) σ
D2(u,u
0
,c
0
,r,P
0
)
σ
0
.
(D3) σ
D3(u,u
0
,c
0
,c,R
0
)
σ
0
.
(D4) σ
D4(u,u
0
,c
0
,c,P
0
)
σ
0
.
C2RBAC: An Extended Capability-Role-Based Access Control with Context Awareness for Dynamic Environments
823

3.3 Extended Models
Based on the C2RBAC0 model, we develop a
C2RBAC family similar to RBAC96 model (Sandhu
et al., 1996). C2RBAC1 and C2RBAC2 are exten-
sions of C2RBAC0 by introducing role hierarchy and
constraints, respectively, that are essentially the same
as for RBAC1 and 2. Furthermore, similar to the
RBAC96 model, C2RBAC3 is obtained by the com-
bination of C2RBAC1 and C2RBAC2.
Formally, C2RBAC1 is obtained from C2RBAC0
by adding the following component:
• rh
i
, a partial order over Role
i
, called role hierar-
chy. (The infix notation r
0
≥
i
r is also used to de-
note role hierarchy and we can say “r
0
is senior
role of r” or “r is junior role of r
0
” in the same
sense as in the RBAC96 model.)
C2RBAC1 is as C2RBAC0 (Definition 1) where
conditions (C0-1), (C0-2), (C0-3), and (C0-6) are
respectively replaced with the following conditions:
(C1-1), (C1-2), (C1-3), and (C1-6).
(C1-1) ses r
i
(s) ⊆ {r | ∃r
0
≥
i
r(hses u
i
(s),r
0
i ∈
URA
i
)}, means any role activated by a session is
one that is assigned to the user who establishes the
session.
(C1-2) ses r
i
(s) ⊆ {r | r
0
≥
i
r(hses cxt
i
(s),r
0
i ∈
SRA
i
)}.
(C1-3) Session s has the permissions
S
r
0
∈ses r
i
(s)
{p | ∃r ≥
i
r
0
(hr, pi ∈ RPA
i
)}.
(C1-6) For any r, r
0
∈ Role
i
and c ∈ C ap
i
, if hc, ri ∈
CRA
i
with r
0
≥
i
r, then session s has the permis-
sions that are determined by (C0-2) above for r
0
,
otherwise (i.e., hc,ri 6∈ CRA
i
) then s has the per-
missions
S
c∈ses c
i
(s)
{p | hc, pi ∈ CPA
i
}.
The former two are related to the role hierarchy,
that are the same as in the RBAC96, while the latter
two guarantee the inheritance of permissions with re-
spect to the role hierarchy.
On the other hand, C2RBAC2 is obtained by
adding various constraints. Typical examples are as
follows.
• Lifetime
• The number of activations
• The number of creations of new capabilities
• The inheritance of permissions related to role hi-
erarchy
• The number of hops of capability transfer
Here we note that the difference between con-
straints and contexts: a state of the system is defined
as an element in Cxt, while the attributes of capabili-
ties are supposed to be not involved in Cxt.
4 CASE STUDY
We demonstrated the effectiveness of C2RBAC for
the eight items described in Section 2 using an exam-
ple of collaborative development between four com-
panies, Companies A, B, C, and D. The example sce-
nario consists of the following five steps. The graphi-
cal presentation is shown in Figure 2, where the solid
and dashed arrows represent the flows of the delega-
tion of authority and access to resources, respectively.
Step 1. To start collaborative development with
Company B (Co.B), the administrator in Com-
pany A (Co.A) assigns the developer role to the
Manager and Alice in Co.A.
Step 2. Alice creates a capability (called c
1
) by exe-
cuting the authority of the developer role and del-
egates it to Bob, a temporary member in Alice’s
team. This capability is limited in the execution
of authority by the following constraints and con-
texts.
• Constraints: expiration date, and prohibition of
capability creation and delegation.
• Contexts: Restriction of the available devices.
This delegation of authority allows Bob to access
the resources required by him to work in terms of
the devices authorized by this capability. More-
over, Bob cannot create new capabilities and del-
egate them to others. To realize the delegation of
authority in this step, the base model needs to pro-
vide items (1) and (2) presented in Table 1 in Sec-
tion 2.
Step 3. Alice creates another capability (called c
2
)
from her developer role, and delegates it to Carol
in Co.B. Here, there is no constraints on c
2
for
delegation of authority, because Co.B is taking re-
sponsibility to develop and manage the web ap-
plication and analyze data and outsources some
tasks to Company C and D (Co.C and Co.D, re-
spectively). On the other hand, c
2
is assigned per-
missions to access the resources with the follow-
ing constraints.
• Constraints: Expiration date.
To realize the delegation of authority in this step,
the base model needs to provide item (4) in Table
1.
Step 4. Carol creates a capability (called c
3
) from
c
2
, and delegates it to David, a data analyst in
Company C (Co.C ). Access rights to the storage
are assigned to c
3
for data analysis. Here, c
3
in-
herits constraints of c
2
, and additional constraints
are imposed, resulting in the following constraints
and contexts.
SECRYPT 2021 - 18th International Conference on Security and Cryptography
824

Administrator
Manager
Alice
Bob
Customers’
Data
Data for
Analysis
Web Log
David Eve
Company A (Co. A) Company B (Co. B)
Carol
c
2
c
1
c
3
c
4
devel
devel
Company C (Co. C) Company D (Co. D)
: delegation of authority
: access
: role “developer”
devel
c
i
: i-th capability
Figure 2: A scenario of collaborative development with multiple companies in dynamic environments.
• Constraints: expiration date, and prohibition of
capability creation and delegation.
• Contexts: limitation of a source IP address.
To realize the delegation of authority in this step,
the base model needs to support item (7) in Table
1.
Step 5. Carol creates another capability (called c
4
)
from c
2
to access resources related to web applica-
tion development and delegates it to Eve, an engi-
neer in charge of the web application development
in Company D (Co.D). The capability c
4
also in-
herits the constraints of c
2
. To continuously oper-
ate the web application, Carol allows Eve to create
new capabilities and delegate them for a limited
number of times as a constraint to only engineers
who belong in Co.D using contexts. As a result,
c
4
is assigned the following constraints and con-
texts.
• Constraints: expiration date, and limit on the
number of creations and delegations.
• Contexts: restriction of available devices, and
restriction of delegation range.
Owing to the constraints and contexts, Eve can
delegate capabilities only to the members in the
same company, and they perform their operations
using only the permitted devices. Therefore, the
base model needs to realize items (2), (4), (6), and
(7) in Table 1.
Capabilities can be revoked by anyone who has
an upper-level capability in a hierarchy of capability;
for example, Alice can revoke all capabilities such as
c
1
, c
2
, c
3
, and c
4
in this case study. If a capability is
revoked, all lower capabilities are also revoked simul-
taneously. For example, if Alice revokes c
3
, c
4
is also
revoked. Furthermore, anyone who has an upper-level
capability can confirm a history of creation and the
delegation of all lower-level ones. These features sat-
isfy items (3), (5), and (8) in Table 1. Consequently,
we have shown that C2RBAC can support all items in
Table 1.
The above scenario can be formally described by
the state transitions shown in Section 3.2 as follows.
Step 1. D
1
(Admin, Manager,devel, admin,{devel})
and D
1
(Admin, Alice,devel,admin, {devel}).
Step 2. D
2
(Alice, Bob, c
1
,devel, {devel}).
Step 3. D
2
(Alice,Carol,c
2
,devel,
{May(Data, access), May(Web, access)}).
Step 4. D
4
(Carol, David, c
3
,c
2
,{May(Data,access)}).
Step 5. D
4
(Carol, Eve,c
4
,c
2
,{May(Web, access)}).
C2RBAC: An Extended Capability-Role-Based Access Control with Context Awareness for Dynamic Environments
825

5 CONCLUSIONS AND FUTURE
WORK
We proposed a new access control model, C2RBAC,
based on CRBAC with a mechanism of context-aware
control. To realize secure, flexible, and scalable
access control for dynamic environments, C2RBAC
provides context-aware capability management, such
as restricting delegation range, while maintaining
the flexibility and scalability of CRBAC. Similar to
CRBAC, we described model families C2RBAC1,
C2RBAC2, and C2RBAC3. In addition, we demon-
strated the effectiveness of C2RBAC by comparing it
with other models and using an example of collabora-
tive development.
For future work, we will define protocols of
context-aware capability management to feasibly im-
plement C2RBAC and develop a formal method for
security verification. In particular, we are interested
in a method for detecting unintended capability prop-
agation by searching all possible delegation processes
using a model checking approach. We are also inter-
ested in implementing a prototype of C2RBAC.
ACKNOWLEDGMENTS
We would like to thank the anonymous reviewers
whose comments/suggestions helped improve this
manuscript.
REFERENCES
Al-Kahtani, M. A. and Sandhu, R. (2002). A model for
attribute-based user-role assignment. In 18th Annual
Computer Security Applications Conference, 2002.
Proceedings., pages 353–362. IEEE.
Baldauf, M., Dustdar, S., and Rosenberg, F. (2007). A sur-
vey on context-aware systems. International Journal
of Ad Hoc and Ubiquitous Computing, 2(4):263–277.
Covington, M. J., Long, W., Srinivasan, S., Dev, A. K.,
Ahamad, M., and Abowd, G. D. (2001). Securing
context-aware applications using environment roles.
In Proceedings of the sixth ACM symposium on Ac-
cess control models and technologies, pages 10–20.
Hasebe, K. and Mabuchi, M. (2010). Capability-role-based
delegation in workflow systems. In IEEE/IFIP 8th In-
ternational Conference on Embedded and Ubiquitous
Computing, EUC 2010, Hong Kong, China, 11-13 De-
cember 2010, pages 711–717. IEEE Computer Soci-
ety.
Hasebe, K., Mabuchi, M., and Matsushita, A. (2010).
Capability-based delegation model in rbac. In Pro-
ceedings of the 15th ACM symposium on Access con-
trol models and technologies, pages 109–118.
Jin, X., Krishnan, R., and Sandhu, R. (2012). A unified
attribute-based access control model covering dac,
mac and rbac. In IFIP Annual Conference on Data
and Applications Security and Privacy, pages 41–55.
Springer.
Kulkarni, D. and Tripathi, A. (2008). Context-aware role-
based access control in pervasive computing systems.
In Proceedings of the 13th ACM symposium on Access
control models and technologies, pages 113–122.
Levy, H. M. (1984). Capability-Based Computer Systems.
Butterworth-Heinemann, USA.
Park, S.-H., Han, Y.-J., and Chung, T.-M. (2006). Context-
role based access control for context-aware applica-
tion. In International Conference on High Perfor-
mance Computing and Communications, pages 572–
580. Springer.
Sandhu, R. S., Coyne, E. J., Feinstein, H. L., and Youman,
C. E. (1996). Role-based access control models. Com-
puter, 29(2):38–47.
Schefer-Wenzl, S. and Strembeck, M. (2013). Modelling
context-aware rbac models for mobile business pro-
cesses. International Journal of Wireless and Mobile
Computing 3, 6(5):448–462.
Snyder, L. (1981). Formal models of capability-
based protection systems. IEEE Trans. Comput.,
30(3):172–181.
Strembeck, M. and Mendling, J. (2011). Modeling Process-
related RBAC Models with Extended UML Activ-
ity Models. Information and Software Technology,
53(5):456–483.
Zhang, X., Oh, S., and Sandhu, R. S. (2003). PBDM: a
flexible delegation model in RBAC. In Ferrari, E.
and Ferraiolo, D. F., editors, 8th ACM Symposium on
Access Control Models and Technologies, SACMAT
2003, Villa Gallia, Como, Italy, June 2-3, 2003, Pro-
ceedings, pages 149–157. ACM.
SECRYPT 2021 - 18th International Conference on Security and Cryptography
826