Information Technology Reference
In-Depth Information
TOCert
1
TICert
2
TOCert
2
TICert
1
TIPw
2
TMCert
2
TMCert
1
TOPw
1
TOPw
2
TIPw
1
BCert
TMPw
1
TMPw
2
BPw
Fig. 5.
Context-dependent Role Hierarchy
PO
3
=
PO
1
× PO
2
In Sect. 4, we provided two sample hierarchies for collaboration environment roles
and contexts. For context-dependent access control, we will create a new role hierarchy
by utilizing the direct product of partial orders. For that, we assume the two hierarchies
to be independent from each other, i.e., there are no inferences between roles and con-
texts. The resulting role hierarchy integrates the context parameter into the collaboration
environment role hierarchy. Therefore, it provides context-dependent access control for
collaboration environments, where the context, i.e., the identification mechanism se-
lected by the user, is used as a parameter for the access control decision.
Since both hierarchies are partially ordered sets, the result is a partially ordered set
again, and thus, can be interpreted as a role hierarchy. Figure 5 presents this new role
hierarchy. It includes all new introduced roles, which are the result of the direct product
of
PO
1
and
PO
2
, and depicts the inheritance relations among these roles.
We will explain some of the roles in order to give an impression of the meaning
of particular roles. For example, role TMPw
1
is for all team members of project
T1
which identify themselves with password. In contrast, role TMCert
1
is for team mem-
bers of project
T1
which identify themselves with certificates. TMPw
1
should provide
less permissions, since the protection level is lower than for TMCert
1
. We may, for ex-
ample, think of the following permissions. Role TMPw
1
has the permission to initiate all
communication tools except, for billing reasons, PSTN telephony, while role TMCert
1
has the permission to make PSTN telephone calls (and inherits all the permissions of
TMPw
1
, of course). Additionally, the new role hierarchy includes a role TIPw
i
,
,
which has the permission to invite new team members, but forbids dropping the project
workspace, and a role TICert
i
which also allows deleting the project workspace. Table 1
gives a summary of all roles. The table shows the particular role according to the project,
the user's role within the project and the chosen identification level.
i
=1
,
2
7 Discussion
The approach above uses the actually chosen identification mechanism as a context pa-
rameter. However, this is only an example; one may think of many other contexts. In
addition, our approach can be generalized to consider more than one context simulta-
neously by applying the direct product to the basic role hierarchy and several context
hierarchies.
7.1 Automated Role Activation
After having generated the complex role hierarchy, we explain how roles can be activated.
In general, if a user is assigned to several roles, it is up to him to decide which role(s)
