or dynamic (Lupu and Sloman 1999, Dunlop et al.
2003); static conflicts can be detected in advance (at
“compile time”), whereas dynamic conflicts are
dependant on “run time” state and thus cannot be
detected in advance.
Conflict detection involves the identification of
actual or potential policy conflicts. Methods for
automatic conflict detection focus on analysing all
policies relating to particular subject/action/target
tuples and identifying whether the there is a conflict
between the modality of these policies. Policies are
generally constructed to reflect the obligation,
permission and prohibition modal operators of
deontic logic, thus modality conflicts are exhibited
by policy pairs that, for a given subject/action/target,
indicate behaviour that is prohibited vs. allowed,
obliged vs. prohibited or obliged vs. not obliged.
Other kinds of conflict detection, in particular those
relating to the semantics of the policies, are
significantly more difficult to detect automatically.
Once potential policy conflicts have been
detected, a decision must be made as to whether to
seek to resolve the conflict, with this decision being
application-specific, but typically related to the
probability of occurrence of the identified conflict.
Two approaches to conflict resolution are possible:
revoke, re-specify and re-deploy offending policies,
or let the system assign precedence levels that
dictate which of the conflicting policies are actually
invoked. The latter approach is more practical, and
researchers have investigated/adopted numerous
schemes for assigning policy preference, for
example see (Lupu and Sloman 1999, Dunlop et al.
2003). For example, precedence can be assigned
based on: specific policies overriding general
policies; newer policies override older policies;
policies specified by a higher authority overriding
those specified by lower authorities; negative
policies overriding positive policies and vice versa;
or explicit assignment of policy weights to govern
precedence. These schemes all have strengths and
weaknesses, but it is agreed that none is suited for
use in all application scenarios.
In our case, policies can be authored by
individual users, as well as by administrators of
systems. Sets of users in a physical space are likely
to have policies with the potential to conflict with
each other, and/or with system policies. We envisage
policy conflict detection and resolution being
performed every time the set of users in a space
changes (as users enter/leave), or as the activities
they are performing change (for example, a project
meeting commences in a meeting room). We view
the former as a form of static conflict detection and
the latter more as dynamic conflict detection. We see
conflict resolution based on higher authorities
overriding lower authorities as the most appropriate
scheme in our scenario: system policies are given
precedence over user policies, and between users
precedence is based on users’ profile, including their
current roles within the space. User roles are
assigned in accordance with system policies and
may change over time. For example, in a meeting
context, a user may be assigned a speaker role when
he/she is detected as standing on a podium, and
system policies will dictate that speakers have
control over the projector, lights and other resources.
In this case that user’s policies relating to, for
example, lighting settings, will have precedence
over those of other users.
3 M-ZONES ACCESS CONTROL
(MAC) PROCESS
The M-Zones access control solution we propose has
been realised in the context of a “Ubiquitous
Management Architecture” (UMA) (Barrett et al.
2004), developed as part of the M-Zones research
programme (M-Zones 2005); which approaches
management of ubiquitous computing environments,
specifically smart spaces, by introducing the concept
of “Managed Zones” (M-Zones) corresponding to
administrative domains encompassing one or more
distinct smart spaces. The UMA adopts a policy-
based management approach to facilitate intra- and
inter- smart space management, with policy decision
points (PDPs) organised in two levels, following the
hierarchical approach described in (Ghamri-
Doudane et al. 2004). The PDP at the upper
(M-Zone) level is responsible for all high level
policies relating to the administration of the smart
spaces. At the lower (smart space) level PDPs and
PEPs control the discovery and execution of
services. Ongoing decision making relating to access
rights occurs at the M-Zone level, with access rights
being communicated to individual smart spaces in
the form of access control lists, which are enforced
by the local PDP and PEPs.
There are two other UMA components involved
in access control: the Context Information Manager
(CIM) and Personal Information Managers (PIMs).
The CIM is responsible for gathering, aggregating
and semantically enhancing context information
subscribed to by the M-Zone PDP and notifying the
M-Zone PDP when context changes occur. Each
user has associated with him/her a PIM, which stores
their user profiles, preferences and policies, and also
acts as their interface to the system. Operation of the
CIM and PIMs is described in (Barrett et al. 2004).
USER-CENTRIC ADAPTIVE ACCESS CONTROL AND RESOURCE CONFIGURATION FOR UBIQUITOUS
COMPUTING ENVIRONMENTS
351