Information Technology Reference
In-Depth Information
×
=
P
Q
P × Q
Fig. 4. Direct product P × Q
4.2 Context Hierarchy
In Sect. 2, we have mentioned that different identification mechanisms provide different
levels of protection. Thus, access control systems, which use identification results for
their access control decisions, should take this level of protection into consideration.
Consequently, in context-dependent access control systems, where the relevant context
parameter is defined by the identification mechanism, there should be different levels
of permissions which depend on the context parameter. In classical RBAC, different
levels of permissions are aggregated to roles. If the usage of different identification
mechanisms implies different permissions, then these mechanisms should influence the
composition of the corresponding roles in role engineering. This means that the iden-
tification mechanisms such as certificates in combination with a challenge & response
protocol, passwords, or cookies will be considered in the definition of roles.
We illustrate this idea by means of a sample hierarchy for protection levels, i.e.,
the context hierarchy. Suppose a collaboration environment supporting two kinds of
identificationmechanisms: identification by user name / password, and by an asymmetric
key pair / certificate. This is depicted in Fig. 4.1. If a user A is authorized to access a
collaboration environment by identifying with a certificate in a challenge & response
protocol, then user A will be assigned to a context Cert
PO 2 . The context Cert
is authorized for a specific permission set PS cert
PERMS . Another user B which
decided to identify himself with a password should be authorized to a context PW
PO 2 . Analogously, he is authorized for permission set PS Pw
PERMS . If both users
identify themselves with their chosen identification mechanisms, they are automatically
authorized for the permissions which are assigned to their corresponding roles.
With the introduction of roles, administration tasks become more efficient. A whole
set of users can obtain newpermissions by just assigning newpermissions to their specific
role. For changes in the access policy for contexts like Cert or PW , this adaption can be
done easily. In practice, the role hierarchy and the context hierarchy can bemore complex
than shown in the example. In real-world collaboration environment examples, theremay
be more roles necessary in order to express the relevant access control categories for
permission assignment. In this context, there may be further roles for the categorization
of tasks within a project or the support of sub-groups of members within projects, e.g.,
roles for different work packages with corresponding permissions. However, the roles
given in the example above might be sufficient in order to get the idea on how to deal with
the problem of different security levels of identification mechanisms in access control,
and how to construct more complex role hierarchies.
5 Arithmetic over Partially Ordered Sets
The properties of partially ordered sets required for our purposes will be outlined in this
section. Since the theory of partially ordered sets is well-understood and described in
Search WWH ::




Custom Search