Information Technology Reference
In-Depth Information
The opposite is not true, i.e., if
(
auth perms
(
r
2
)
⊆
auth perms
(
r
1
))
∧
(
auth usrs
(
r
1
)
⊆
auth usrs
is fulfilled, then it is still up to the role engineer to decide whether to
introduce an inheritance relation between
(
r
2
))
r
2
or not. Multiple inheritance means
that a role inherits both permissions and role memberships from two or more roles.
With the concept of multiple inheritance, these hierarchies provide a powerful means
for role engineering, i.e., it is possible to construct roles from many junior roles. Role
hierarchies are modeled as partial orders. Fig. 4.1 in the next section depicts a sample
role hierarchy.
r
1
and
Role Activation and Sessions.
In a role hierarchy, a senior role inherits the permissions
from the junior role. But a user does not necessarily have to act in the most senior
role(s) he is authorized for. Actual permissions for a user are not immediately given by
evaluating the permission assignment of his most senior role(s); these roles can remain
dormant. Instead, actual permissions depend on the roles which are activated. A user
may decide which roles to activate. Sessions are defined over phases in which users
keep roles activated. A user's session is associated with one or many roles.
Principle of Least Privilege.
The principle of least privilege requires that a user should
not obtainmore permissions than actually necessary to performhis task, i.e., the user may
have different permissions at different times depending on the roles which are actually
activated. As a consequence, permissions are revoked at the end of sessions.
Static Separation of Duty.
In some security policies, theremay arise a conflict of interest
when users get some user-role assignments simultaneously. The idea of static separation
of duties is to enforce some constraints in order to prevent mutually exclusive roles. In
the presence of a role hierarchy, inheritance relations have to be respected in order to
avoid infringing these constraints.
Dynamic Separation of Duty.
The goal of dynamic separation of duty is - similar to
static separation of duty - to limit permissions for users by constraints in order to avoid
potential conflicts. The difference here is that these constraints define which roles are not
allowed to be activated simultaneously, i.e., the constraints focus on activation of roles.
Roles obeying these constraints can be activated when they are required independently,
but simultaneous activation is refused.
Further Relevant Properties.
RBAC is assumed to be policy-neutral. This means that
RBAC provides a flexible means to deal with arbitrary security policies. It is highly
desirable to have a common means to express a huge range of security policies.
In classical role-based access control work, roles are assumed to be related to jobs or
functions of persons in enterprises or institutions with some associated semantics which
express authority and responsibility. In the following, we will show how RBAC can be
used in order to solve access control problems for collaboration environments where
permissions are dependent on the underlying identification mechanism as a context-
dependent parameter of interest.
4 Role Hierarchy and Context Hierarchy
The reason for introducing roles was to efficiently assign users to specific sets of permis-
sions. If a member of a role tries to initiate an operation on an object, where this role is not
