Role-based access control, RBAC, is an approach to protection through access control, where, access decisions are based on the roles that individual users have as part of an organization. Users take on assigned roles (such as doctor, nurse, teller, manager). The process of defining roles should be based on a thorough analysis of how an organization operates and should include input from a wide spectrum of users in an organization.
Though the historical reason for RBAC, and most other work on access control, is to devise methods for protecting IT resources from being access in unauthorised ways by users, we reformulate the basic paradigm in a way that makes it applicable to protection of users in a decentralised environment.
In RBAC, roles can have overlapping responsibilities and privileges; that is, users belonging to different roles may need to perform common operations. Some general operations may be performed by all employees. In this situation, it would be inefficient and administratively cumbersome to specify repeatedly these general operations for each role that gets created. Role hierarchies can be established to provide for the natural structure of an enterprise. A role hierarchy defines roles that have unique attributes and that may contain other roles; that is, one role may implicitly include the operations that are associated with another role.
Two major forces have been driving the development on RBAC: to be able to model, in a rational ways, what access control means, so that a set of control specifications have a meaning that is clear; and to be able to offer mechanisms whereby the administration of a set of control specifications becomes manageable. The concepts of roles and role hierarchies provide the key to making management feasible.
In the area of privacy protection in the style of P3P, a similar problem reappears. Just as we, in the real world, adapt our privacy preferences to the current situation, and evolve our privacy preferences over time, we need to be able to smoothly do similar adaptation and evolution in the networked space, e.g. the web. The P3P language did not focus explicitly on this area of concern. But it is possible to add this kind of support, by adding preference management functionality to our toolbox.
In a way, one can see this approach as an application of the concept of a layered machine, composed of different engines, one on top of the other, where the lowest level is the "P3P engine" and the highest is the end-user "preference management engine".
The approach taken is to adopt, and adapt, the concepts of roles and hierarchies from RBAC, and apply this to privacy preferences.
|
This activity was partly supported by grant IST-2000-28767 from the European Union's Information Society Programme to the Question How project |