Information Technology Reference
In-Depth Information
UA
PA
users
operations
permissions
objects
roles
Fig. 2.
UA
and
PA
using an asymmetric key pair / certificate. In this scenario, a possible attacker obtaining
the team initiator user name and password may only invite new members, but is not
able to destroy existing projects. The considerations above show that there are good
reasons to differentiate different kinds of access to resources depending on the level of
identification. Figure 1 summarizes the aspects mentioned above in a
domain model
as
it is used in software engineering.
3 Role-Based Access Control
In this section, the main ideas in RBAC are presented. Since the general concepts of
RBAC are well-understood and extensively described in the literature [8,12], we will
only briefly describe the key aspects.
Basic Idea.
The central terms inRBAC are
user
,
role
, and
permission
. Therefore, we have
sets
USERS
,
ROLES
, and
PERMS
. For elements of these sets, we have two assignment
relations
UA
ROLES
. The
user assignment
UA
defines a relation between users and roles, whereas the
permission assignment PA
defines the relation between roles and permissions. Both relations are many-to-many.
The set of all permissions is obtained by the combination of
operations
and
objects
,
i.e.,
PERMS
⊆
USERS
×
ROLES
and
PA
⊆
PERMS
×
OBS
, where
OPS
and
OBS
are the corresponding sets. Types
of operations depend on the type of system which is considered. In access control ter-
minology, an object is an entity which contains or receives information, e.g., an object
may be a file or some exhaustible system resources. If a user
=
OPS
×
u ∈
USERS
changes to a
new user category leaving his old role
r
old
then he is simply assigned to a new role
r
new
by getting the permissions of
r
new
and losing the permissions of
r
old
. RBAC facilitates
security management, makes it more efficient, and reduces costs.
Role Hierarchy.
Role hierarchies are thought to be one of the most desirable features
in RBAC. They are very useful when overlapping capabilities of different roles result in
common permissions because they allow to avoid repeated permission-role assignments.
This allows to gain efficiency, e.g., when a large number of users is authorized for
some general permissions. Role hierarchies
RH
ROLES
are constructed
via inheritance relations between roles, i.e., by the introduction of senior and junior
relations between roles
⊆
ROLES
×
r
1
r
2
in such a way that the senior role
r
1
inherits permissions
of the junior role
r
2
. To put it more formally, if we have roles
r
1
and
r
2
with
r
1
r
2
,
then
(
auth perms
(
r
2
)
⊆
auth perms
(
r
1
))
∧
(
auth usrs
(
r
1
)
⊆
auth usrs
(
r
2
))
. These
mappings are defined as
|r
r,
(
p, r
)
∈
•
auth perms
:
ROLES
→
2
PERMS
,
auth perms
(
r
)=
{p∈
PERMS
PA
}
,
USERS
|r
r,
(
u, r
)
∈
•
auth usrs
:
ROLES
→
2
,
auth usrs
(
r
)=
{u ∈
USERS
UA
}
.
