Information Technology Reference
In-Depth Information
to the underlying security policy (static separation of duties), or users cannot be activated
for conflicting roles simultaneously (dynamic separation of duty). The example we have
introduced in figure 5 does not make use of separation of duty aspects. However, in a
concrete collaboration environment, there may be other constraints which follow from
potential conflicts resulting from the underlying security policy. E.g., consider a model
in which a user can only be active in a single project per session. This means that, he
explicitly needs to log in to and log out from a particular project. While working in that
project, each request to a resource needs to be checked, whether it is a resource of the
current project; if not, then the user has to be informed that he needs to exit the current
project, first. This scenario could be modeled using constraints.
8 Related Work
In the past years, there have been various contributions to the area of RBAC which
emerged as an alternative of classical discretionary and mandatory access control ap-
proaches. Ongoing research activities in RBAC resulted in the first proposed NIST
standard for RBAC [8]. In the past, RBAC was mainly used for database management
and network operating systems. Up to now, there are only a few contributions consider-
ing the usage of RBAC in the web context, even if RBAC is assumed to be a promising
alternative for this area [10]. But in practice, protection on the web is still dominated
by traditional concepts [9], e.g., access control lists. The first proposals for the usage of
RBAC for the WWW is given in [15,16,17].
In the PERMIS project a role-based access control infrastructure was developed that
uses X.509 certificates [18]. In this work, user roles and the permissions granted to
the roles are contained in X.509 attribute certificates. In contrast to this approach, we
do not store roles and permissions in attribute certificates since certificates have to be
renewed after some period, and they can become invalid before their expiration date,
which requires the introduction of revocation mechanisms.
The Generalized Role-Based Access Control approach [19] models contexts in res-
idential computing infrastructures using object roles and environment roles. Georgiadis
et al. developed a model for team-based access control using contexts (C-TMAC) [20]
by providing user contexts (e.g., the team membership) and object contexts (e.g., set of
objects required for certain tasks). In these works, contexts are not integrated into the role
hierarchy. Instead, they store them in a separate structure. The contexts are considered
as an additional step in each access control decision.
The second aspect of our work deals with the context-dependency respecting security
level of identification for access control decisions of web-based collaboration environ-
ments which has not been considered so far. In our opinion, this idea is of high relevance
for access control in web-based collaboration environments, where mobile users cannot
always access the collaboration environment via their own computers.
9 Conclusion
In this work, we have shown how to model access control for web-based collaboration
environments with RBAC since RBAC provides promising properties for controlling
