Information Technology Reference
In-Depth Information
requests
Collaboration Environment User
Operation on Object
Constraint
allows / refuses
uses
assigned to
influences
Team Role
Access
Control
influences
Identification Mechanism
Fig. 1.
Context-dependent access control
configured on a team basis. Thus, there may be different services available in different
teams. In the same way, security policies are configured on a work context basis, i.e.,
teams may different security policies. The features provided by today's collaboration
environments can be considered to be basic services which may comprise one or more
operations on objects on the web server side. The users' requests to apply these opera-
tions on objects have to be checked against the underlying security policy. Of course,
if operations are not allowed for all users, such a check requires that the identity of the
requesting user has been verified through a well-chosen identification mechanism, ade-
quate for the values to be protected. The support of different identification mechanisms
and the consideration of the chosen mechanism in the access control decision may be
relevant in collaboration environments, as it will be explained below. Here, the goal is to
consider the specific mechanism which is used for identification as a context parameter
for access control decisions.
Context-dependent access control can be motivated as follows. Consider a mobile
worker with the intend to access his collaboration environment from his own computer
but also from a public computer somewhere in the world.Assume that from his computer
at his office this user identifies himself to the collaboration environment through the
possession of his private key and his certificate. For sensitive operations, high security
level provided by an asymmetric key pair / certificate identification is necessary. Assume
now, that the same user wants to use the collaboration environment while he is traveling
and only having access from an Internet cafe or from a machine in a partner company by
using a web browser. Such a user would not want, or is not allowed, to expose his private
key to a potential untrusted environment. In this case, password identification might
be desirable for less critical operations. However, for security reasons, more critical
operations should be refused when the user identifies himself using a password. In the
context of collaboration environments, critical operations are, e.g., the deletion of a
project's workspace, and the modification of account data, while a less critical task is a
lookup in the project's address book.
Within a collaboration environment one can consider various roles. First, there are
different projects; some users may have access to project
T1
and project
T2
while others
may only have access to project
T2
. Second, there are different roles within a project.
For example, besides a default project member role, there may be a role project initiator,
which is assigned to the user that creates and deletes the project and invites new team
members, or there may be a project operator role, which is assigned to users that are
responsible for configuring the project resources. Suppose now a security policy where a
project initiator may invite new team members when he identified with either password
or asymmetric key pair / certificate. But for deleting the project, he needs to identify
