Abstract
Context-aware access control systems should reactively adapt access control decisions to dynamic environmental conditions. In this paper we present ERBAC – an event-driven extension of the TRBAC model that allows the specification and enforcement of general reactive policies – and its implementation. While almost all the individual features of ERBAC occur separately in some previous model, the detailed design of the policy language, its implementation in XACML, and its testing contribute to the development of expressive, event-driven policy frameworks by demonstrating that this rich model can be satisfactorily implemented, and that its expressivity and performance are compatible with a variety of realistic application scenarios. In particular, a number of examples illustrate ERBAC’s expressive power, and its ability of handling exceptional situations in a flexible way, while keeping policies compact and manageable. The prototype extends XACML’s language and the implementation of the PDP to support the new model. Systematic scalability experiments show that the computational cost of policy rule evaluation in ERBAC is compatible with real-world applications.
Introduction
The advent of pervasive/ubiquitous/mobile systems has increased the expressiveness requirements on policy models and languages, as well as the complexity of access control decisions. In such systems, the decision of whether a permission should be granted or not may depend on a number of dynamic environmental conditions. First of all, such a decision might depend on where the user is. The formulation of the current user position depends on the application scenario; space may be divided into several logical areas. On the one hand, the access control system might be used to control user access to restricted areas, e.g., accessing an operating room in a hospital should be allowed only to authorized personnel and patients. On the other hand, the user location might be used as a condition for granting access to some resources, e.g., an employee can read her work email marked “confidential” only whenever she is within specific offices in one of the company buildings. A second important variable is when access is requested. An example is the case in which the policy needs to limit the access to some resource during specific time intervals, e.g., the bank vault should be open every working day between 8:00 a.m. and 4:00 p.m.
The ability of interacting with the environment is a characterizing feature of pervasive and ubiquitous systems. Such systems are able to obtain information from the environment and possibly use that information to influence the environment itself. The events detected by monitoring the environment may be exploited to adapt access control policies to particular – possibly exceptional – situations. Consider the following simple example: Fire extinguishers should be, under normal circumstances, inaccessible; in case of fire, everybody who is close to the fire should be able to access fire extinguishers for 30 min after the alarm. Such a scenario clearly describes the interplay between the environment and spatio-temporal conditions. If the environment does not sense any fire, nobody is able to access fire extinguishers. In order to express this policy, a language is needed where policy rules can be triggered by a rich range of environmental conditions and events. Furthermore, in the example, access permission is limited only to a category of resources (extinguishers) that are spatially and temporally bounded (close to the fire and for the first 30 min from the alarm).
Several policy models extending standard models with spatiotemporal conditions have been studied, and some prototypes where policies are driven by sensor inputs have been experimented with. Still, some work remains to be done before a general purpose, spatiotemporal, and event-driven policy framework can be built. One reason is that the works in the literature focus on specific aspects (e.g., policy model only, implementation only, spatial or temporal conditions only, etc.). A fully detailed, general purpose, and event-driven policy language assessed with an extensive systematic validation is still missing. More precisely, a framework with all of the following features is still missing.
The policy framework should be essentially policy neutral, in order to be general purpose, that is, it should be expressive enough support a variety of policies based on dynamic environment conditions. The language should also be structured so as to facilitate the formulation, validation, and maintenance of complex policies, e.g. by incorporating models such as RBAC (that facilitates permission and user handling)1 The RBAC paradigm [30,37–39] solves this issue by interposing roles between users and permissions, that is, permissions are assigned to roles and roles are assigned to users. This greatly simplifies the tasks of adding and removing users, as well as changing their role in the organization. Another appealing feature is that the assignment of permissions to roles, which is perhaps the most delicate aspect in policy authoring, is relatively persistent. Moreover, when this mapping needs to be changed, it does not need to be reflected manually on a multitude of individual users. The success of RBAC models is also due to the fact that roles are a natural way of representing job functions within an organization [15,39].
Policies and mechanisms should be clearly separated, according to a widely advocated practice. In some systems, policies are merged with the application code, and coded with the same language; this lack of structure makes it more difficult to understand, validate, and maintain policies, and makes them vulnerable to a wide range of programming errors. Such programming-framework approach is also in conflict with the following requirement.
A complete, formal definition of syntax and semantics of the policy language should be specified. Without such definition, the expressiveness boundaries of the policy language are not clearly specified, which prevents systematic testing of the language’s performance as policies become more complex. Some papers present the language by way of examples; there is no closed list of operators. On the one hand, when some example cannot be captured right away, one may postulate the existence of more operators; in that case, however, the reported experiments (if any) do not reflect the impact of the new operators on language performance. A similar difficulty is encountered with some fully abstract policy models that represent time and space as generic sets of points, without providing any concrete syntax for spatiotemporal operators; experiments need concrete syntax and operators to be carried out. Some implemented systems lack a formal semantics, which has serious implications in terms of potential ambiguities and security flaws, and it prevents any sound validation of security monitors.
The expressiveness of the policy framework should be validated by means of articulated examples. Emergency handling is of particular importance in pervasive computing applications; nonetheless only a few papers deal with this issue.
The practical applicability of the policy language should be further assessed by means of systematic scalability tests, so as to understand whether the nice dynamic constructs supported by a rich policy language can be actually used in practice.
In this paper we contribute to the design of a general purpose, spatiotemporal and event-driven policy framework by tackling the aforementioned gap, that is, by: (i) specifying a fully detailed, expressive policy language, (ii) assessing its expressiveness by modelling articulated scenarios, including emergency handling situations, (iii) implementing the framework using as much as possible standard components, languages, and protocols, and (iv) carrying out systematic scalability tests. Here are more details:
A complete definition of syntax, including spatiotemporal operators, is provided, together with its formal semantics. Concerning expressiveness, the language supports: (i) roles and role templates, by adopting a rich, event-driven extension of the RBAC model, that we call ERBAC; and (ii) policy composition, by merging the dynamic features of ERBAC into XACML. The structure of XACML (in particular, its TARGET element) is very effective in selecting the relevant portion of a large policy for each access control decision, which may significantly improve the performance of the policy decision point. Detailed and complete syntax enables both formal semantics definition and sound expressiveness and scalability analysis, as explained in the previous paragraphs. The policy model ERBAC comprises a rich set of features that occurred separately in previous models. Of course, such features include spatiotemporal conditions and event-based conditions. The representation of time is inherited from the TRBAC model, and the representation of space supports logical and physical locations, as well as location types (which is less common in the literature, but very useful in formulating policies). Behaviour is properly event-driven (in some other models the access control mechanism reacts only to standard (subject, object, operation) access requests). We introduce the notions of personalized and localized events in order to control the extension of event effects. In response to spatiotemporal and other dynamic conditions, ERBAC policies can enable and disable roles. Role templates are important, too, as they play a fundamental role in e-health applications (e.g. permitting access to the medical record of a given patient only to her doctor, as opposed to all doctors), that constitute a recurring reference scenario for dynamic policy models. Table 1 summarizes the differences between ERBAC and the other models with similar goals. The expressiveness of the language’s constructs is assessed through a number of articulated examples in Section 7. Our main reference scenario is focussed on the management of hospital resources, but we provide also some other examples to illustrate the general applicability of the framework. We explicitly address emergency handling policies – an important issue in medical and domotic applications, which is not widely addressed in the literature. The key language feature for emergency handling is policy overriding. In particular, by means of priority-based overriding and localized events, we show how to relax location-based policies (similar effects can be obtained for time-based policies, as well). We introduce and describe a prototype implementation of ERBAC that extends Sun Microsystems’ implementation of XACML [41]. The extension of XACML with dynamic conditions and spatiotemporal operators answers the following practical question: do the extension points of the XACML standard suffice to incorporate the dynamic feature of ERBAC? We answer positively this question by providing the details of an extension of XACML that fulfills this requirement. The performance of part of the language features (such as policy composition) have been already assessed in previous work. Here we focus on the scalability of spatiotemporal conditions, by means of an original suite of systematic scalability tests. Currently, the language does not support event composition operators (such as sequence, co-occurrence, and so on); accordingly, scalability along that complexity dimension lies beyond the scope of this paper. In our reference examples, similar functionalities can be simulated using event attributes and the other constructs of the language. is expressive enough to address an interesting range of application scenarios, including some nontrivial emergency handling examples; it can be effectively embedded in industrial-strength standards such as XACML, GeoXACML, and GML; the overhead introduced by composition and spatiotemporal constructs is moderate and compatible with a variety of applications; performance scales well as policies grow larger and more complex.
Our analysis shows that the ERBAC-based policy framework
So, in summary, the ERBAC-based framework assesses the feasibility of a rich, dynamic, spatiotemporal RBAC model.
Organization of the paper. In Section 2 we review previous relevant works in the field. In Section 3 we briefly report the formal definition of the basic RBAC model. In Section 4 we present the basic components that we use in order to represent context conditions. In Section 5 we report the basic terminology and syntax that we use to specify access control policies. In Section 6 we define the formal semantics of the model, and in Section 7 we give a number of examples demonstrating how our system can be used to write context-dependent policies. We further provide a classification of the ERBAC model in the UCON context defined in [31]. In Section 8 we describe the prototype we have implemented and report the results of our experimental analysis. Finally Section 9 reports some concluding remarks and open issues. In order to help the reader, we collected the glossary of main terms and concepts in Table 8.
In role based access control models [36], permission are assigned to users indirectly, through roles. Each permission can be assigned to different roles. Similarly each role can be assigned to different users. This model makes permission-to-users assignment extremely flexible for a number of reasons. First of all, roles can be immediately identified within an organization as they typically match specific jobs, e.g., an accountant, a driver, a branch manager, etc. Given a role, the set of permissions that should be assigned to it can be determined with the need-to-know principle (i.e., by identifying a minimal set of permissions that enables the role’s tasks to be performed). Whenever a user’s responsibility is modified, e.g., she is promoted, it is sufficient to update the set of roles that the user can enable. Furthermore, whenever the organization’s policy changes, it is sufficient to modify the association of permissions to roles. In order to reflect the (typically non-flat) organization chart, roles can be organized hierarchically, i.e., each role inherits all permissions that are beneath it in the hierarchy.
The classical RBAC model may be too coarse-grained for some applications. For example, if role Doctor is authorized to read patient records, then every user playing this role can read the medical records of all patients; it is not possible to restrict the permissions of any specific doctor to the data of her own patients only. This limitation has been addressed in [17] by introducing the concept of parametrized privilege, that is a privilege that can be granted to a particular user only if some condition holds. A restricted privilege can be seen a triple
This model has been enriched by introducing user location [14,32] and temporal conditions [5,6,19]. Further context-aware RBAC models can be found in [3,4,9,10,13,16,19–21,33–35,40]. A comparison of the involved policy models is summarized in Table 1. A wider comparison includes works that do not feature an abstract policy model (nor any formal semantics, in general), and are system-oriented, or programming-framework oriented; it is summarized in Table 2. Notice that (i) we could not simply adopt any existing framework out of the box, since each of them is missing some important feature; (ii) to the best of our knowledge, no systematic scalability tests has been carried out for increasing policy complexity. The details are discussed in the following.
In [13], the authors introduce the concept of environmental role in the Generalized RBAC model (GRBAC), as a mean for reducing the complexity of access control systems in ubiquitous computing. An environmental role is an abstract role that is activated whenever a given set of environmental variables assume specific values, e.g. temperature in room X in the morning below 32°F. In this model a permission, that can be associated with a set of environmental roles, becomes available to users whenever environmental conditions allow the activation of one of the roles in the set. In [12] the authors provide an implementation of GRBAC where access control is managed by means of environmental roles.
A comparison of policy models with some form of dynamic conditions
A comparison of policy models with some form of dynamic conditions
Notes: “Event driven” here means “supporting arbitrary, asynchronous, environment-generated events”. Accordingly, the frameworks that support only temporal events – that can be predicted and scheduled in advance, as in [6] – are not classified as “event driven” in this table.
(1) No syntax/structure is specified for locations.
(2) Simulated with environmental roles.
A comparison of relevant policy frameworks
Notes: “Event driven” here means “supporting arbitrary, asynchronous, environment-generated events”. Accordingly, the frameworks that support only temporal events – that can be predicted and scheduled in advance, as in [6] – are not classified as “event driven” in this table.
(1) No syntax/structure is provided.
(2) Partial.
(3) Syntax is not fully specified.
In [20,21] the authors present Context Aware RBAC (CA-RBAC) and a framework that allows the specification of context aware policies. The system is characterized by applications, each of which can define its own set of roles. Each role is defined by considering context-information like temporal and spatial conditions, pre-conditions that have to be met before the role can be activated and/or context events that describe specific environmental conditions. It is possible to associate to each event a context guard, i.e., a condition that has to be verified whenever the environmental condition changes.
In [22,23] the authors consider a specific application scenario for time-critical applications, namely context-aware access control for patient monitoring systems. In time-critical applications, it should be possible to trade the privacy of the information for the time needed to obtain an access control decision, i.e., against the criticality of current context. In these papers the authors compose different access control policies ranging from quick but coarse decisions in critical conditions to slow but fine-grained ones in normal conditions. Clearly, context-aware decisions are typically hard to achieve if many sensors need to be queried each time an access request is made.
In [2,3,9,10,33,34] the authors present models in which both a spatial condition s and temporal condition t are managed as a single spatio-temporal pair
While the traditional RBAC model requires users to explicitly activate the roles they need (in order to encourage the application of the least privilege principle), several of the frameworks designed for pervasive environments, including [2,14,22,23], support the automated activation and deactivation of roles based on spatio-temporal and event conditions. In some cases, e.g. [12,35], there is no distinction between role enabling and activation. ERBAC follows this approach, nonetheless separate enabling and activation can be easily simulated as shown in Section 5.2. One of the advantages of the automated activation approach is that carefully designed (de)activation conditions relieve the user from the responsibility of enforcing the minimal privilege principle and may provide better guarantees. Another advantage is improved user experience, as activation is determined by the user’s natural interaction with the environment rather than by additional explicit actions that may look redundant to the user. It is our opinion that the attempt to use a resource should also work as a role activation request; in this way, enabling corresponds to the spatio-temporal part of the condition associated to a role’s activation rule, while the activation request corresponds to the event part of the same condition (where the event is generated by attempted resource usage). In such application contexts, we believe that separate enabling and activation constructs are less preferrable than a simpler syntax where the distinction between enabling and activation disappears. We expect only a small number of cases where the distinction is helpful, and in those cases the encoding illustrated in Section 5.2 can be used.
ERBAC is not the main contribution of our paper. Its features have been studied separately elsewhere; unfortunately, none of the above framework exhibits the full set of properties we need (cf. Tables 1 and 2), for example: We cleanly separate policies from the application logic, while [16,20,21,35] do not. In our reactive framework, the environment is monitored continuously (through an event-based mechanism) while [3,16,33–35,40] check policy conditions only once before granting access. Joshi et al. [19] deal only with time and [35] only with space; [9] does not support general events. Strembeck and Neumann [40] do not provide a formal model. Finally, we mention that to the best of our knowledge ERBAC’s notions of personalized and localized events are novel. These considerations led us to introduce a policy model tailored to our goals, even if its novelty is moderate.
Our main contribution is the definition, implementation (including the extension of XACML with reactive policies), and evaluation – in terms of expressiveness as well as performance and scalability – of a rich reactive policy framework. In this respect, note that [3,4,9,13,16,19,33,34] do not illustrate any implementation, and none of the papers mentioned so far contains any experimental scalability testing. Similarly, no work has shown how to embed spatiotemporal conditions and reactive policies in XACML. A preliminary version of this paper appears in [8].
The RBAC model we are going to extend in this paper has been introduced in [36] and consists, basically, of the following components: A set of users U, a set of roles R, a set of permission P and a set of sessions S. A user in U is a human or artificial agent, that can execute operations in the systems, each of which requires a specific set of permissions. A non-empty set of operations defines a job within an organization. A role can be seen as a set of permissions that are needed to execute a given job within an organization. Finally, sessions associate users to roles. After the authentication phase, the system creates a new session during which the user can require the activation of the roles she is allowed to play. Role activation is successful only if the required role is enabled and the user is entitled to activate it. In this case, the user is granted all the permissions associated to the activated role. The model comprises a number of functions defined below. The user assignment (UA) and the permission assignment (PA) functions are used to associate users and permissions to roles, respectively. As stated above, a user can be associated with many roles and every role can be played by many users. Similarly, a permission can be associated with many roles and a role can include many permissions. The user function maps each session to a single user, whereas the function role establishes a mapping between a session and a set of roles. It is possible to define a hierarchy on the set of roles by means of the
The U, R, P and S: Users, Roles, Permissions and Sessions;
In this paper we will extend one of RBAC successful extensions, the TRBAC [6] whose components will be detailed in the next section.
In this section we present the formal model for ERBAC. We will first introduce context representation and, then, we will use such a definition for extending the classical TRBAC model.
Context representation
The context in which an action takes place is identified by three major features: location that describes where the action takes place; time which specifies when the action takes place; and events, that describe other relevant measurable features of the context that may influence the access control decision process.
Time representation
For the representation of temporal assertions we will use the classical formalism introduced by TRBAC [6], which we recall briefly to make the paper self-contained.
Informally a temporal expression is represented as a pair
Let C be a calendar and
Given calendars
The symbol ⊳ separates the set of starting points of the intervals from the specification of the duration of each interval. For example,
Given the above definition we can define:
A temporal expression identifies a set of periodical intervals and is represented by a pair P is a periodic expression.
From TRBAC we further inherit the following functions: In the time-domain we define the following functions:
A position in space can be described with three, orthogonal, representations. The first two have already been used in the context of time-space access control ([3,33,34]). The location of a device can be specified by its position within a Cartesian coordinate system. In this case, the physical location of the device is represented, say, by a triple of coordinates
Given the above, a physical location can be mapped to different logical locations since, for example, a point in space can belong to different logical locations (e.g., room, floor, building, etc.). Similarly, a logical location can describe different physical locations. Notice that a logical location can describe different elements in different logical locations. For example the logical location “room x” can be part2
We will define containment operations shortly.
In the location domain we define the following functions:
It is important to notice that, if there exists some sort of hierarchy over physical and logical space descriptions, then there should be a way of inheriting such a hierarchy also in the space of location types. Furthermore, such a hierarchy on location types should not merely reflect geometrical containment since there might be cases in which priorities need to be assigned to different types of locations. As an example we can consider the types “operating room” and “patient room”. (Typically) there exists no containment relation between rooms of these types, neither at the physical nor at the logical level, but clearly, every logical location that is an “operating room” should be subject to more restrictive access control policies w.r.t. patient rooms.
Thus there are cases in which there exists a hierarchy in the logical organization of space. We say that a location type
Location type ordering is defined as a partial order over the set of location types, ( The relation
Since each logical location can be associated with a number of location types, the relation
Given the above discussion we define a containment relation between logical locations as follows:
Let there exists some location type no location type
We further define a notion of proximity based on the space representation just discussed. We notice that a possible definition of proximity for two physical locations
Let
Intuitively, two physical locations are close if they both belong to the same logical location whose type is the most specific, i.e., the one that guarantees the maximum possible granularity for describing both locations.
With the term event we denote all the aspects of the context that are different from time and space and that are monitored and/or measured. An event can describe, for example “surgery in progress” or “open door”. Events can be classified as localized or global. An event is localized if it is associated somehow to a specific location, e.g., a “surgery in progress” has an impact only in the “operating room” in which the surgery is performed. An event is global otherwise, e.g., a blackout is, in principle, a global event since it can affect the whole space.
We further classify the events based on their generation. In particular an event can be system generated or user generated. An example of the former is the automatic opening of a door while, for the second one, we can think to a medical emergency request by some patient.
Finally we can classify the events based on the set of users it affects. In particular, an event is personalized if it affects some users while it is general if it affects all the users.
We will denote by E the set of all possible events. We associate to each event a priority, that is a natural number in the set
To formalize the above discussion, we will use the following:
Let U be the set of users. In the event domain we define the following functions:
Table 3 contains the taxonomy of events as described above.
Event taxonomy
From the above discussion, it is clear that every event is, in principle, visible only to a subset of user. We will consider two types of visibility. In the first one, the generation of an event in a specific physical location needs to be “propagated” to some extent in the spatial hierarchy. Consider the case of a fire in an office. Although the event is localized, it is reasonable to assume that it will became visible to all the users to other levels in the hierarchy, say in the whole floor or in the whole building. Thus, on the one hand, we have a spatial hierarchy that maps a physical location p into a set of logical locations,
A second type of visibility is related to the “presence” of a user in a specific place. Consider, for example, the case of a medical emergency. It is reasonable to assume that such an event is visible to doctors that are “close” to the event generation location. Similarly, it does not make much sense to alert a doctor that is miles away from the event location. We will discuss events of this type in Section 7.8.
Notice that a non-localized event is, by definition, visible everywhere. Finally, personalized events should be visible only to user to which it is addressed.
Given the above discussions and definitions we are now ready to formally define a context state in terms of time, space and events. Temporal conditions can be expressed either in the form of periodic intervals
The set of temporal condition TCond is such that:
A time instant t satisfies a temporal condition
Similarly we can define spatial conditions as follows.
The set of spatial conditions SCond is such that:
Given a physical location
Using the same strategy we can define conditions on events as follows:
The set of event conditions ECond is such that:
A set of events
A condition on the context can be expressed as the Cartesian product of Let
In this paper we will use role templates and parametrized privileges in order to make privileges context-dependent. For this reason, we need to redefine the sets P (privileges) and R (roles) of the
We will denote by
Since objects and categories may be mapped arbitrarily, we define the following functions:
In the object domain we define:
Since we will use parametrized privileges, we need to define a privilege in terms of an operation, a category and an expression.
Let
An example of the expressiveness induced by the above definition is the following. It is possible to restrict read access to all the objects in the category “Medical Records” that contain a specific “department” attribute by using the parametrized privilege as follows:
Similarly, we will use role templates as a means for defining generic, parametrized roles in our model. We will denote by
Let
We can use role templates to write access policies in a compact way. For example, we may allow each doctor to read each patient record in his own department using the following definition.
In the classical RBAC model, roles are activated whenever an entitled user requests their activation. According to [3,6], a role’s life-cycle is partitioned into two subsequent steps. Initially all roles are disabled. Role enabling modifies the role state from disabled to enabled. Enabled roles are ready for the actual activation that occurs automatically at the first permitted access request. More generally, a context-aware system needs a way to control role enabling and disabling based on context-dependent conditions. We will use the following approach:
(Event Expression, Role Status Expression).
Let ( (Simple) Event Expression: “enable r” or “disable r” are used to enable or disable a role Prioritized Event Expression: These expressions have syntax Role Status Expression: In the form “enabled r” or
As it has been done in TRBAC and in its derived models, we use the term event expression to refer to enabling/disabling requests. However, in the previous models an event was only used to identify policy and/or user requests, i.e., enable/disable role, activate/deactivate role, modify role permissions, modify user-role assignments. In ERBAC the concept of event is much wider and includes, as stated in Section 4.1.3, all the aspects of the context that are different from time and space and that are monitored and/or measured.
When conflicting events arise – that is, if one expression requires the enabling of a given role r and, at the same time, another one requires to disable the same role r – we need a way to decide which one should prevail. We observe that in this decision process, an expression that is bound to a specific user u, e.g., enable r for u, should not influence decisions regarding other users. On the other hand, a general expression, that is not restricted to any specific user, should, in principle, be able to prevail on every conflicting expression that is bound to a single user. Given the above discussion we can define the conflicts between expressions.
Let
Finally, access control policies can be encoded by coupling an event expression with a context-condition in what we call the Conditional Event Expression. From the TRBAC model we inherit the concept of role trigger in order to support the cascading enabling/disabling of roles as an effect of the enabling/disabling of other roles. For the sake of self-containment, we report the original definition.
A Conditional Event Expression is an expression
A Role Trigger is an element in the form:
A Role Enabling Base (REB) is a set of conditional event expressions and role triggers.
Let us assume the following temporal expression:
Furthermore, let Cardiology be a department in a given hospital and let
Such enabling rule will be executed whenever an employee, that has been authenticated using the credentials of a doctor of the Cardiology department, enters any physical location of such a department, during working hours. We assume that user authentication is guaranteed by standard tools, and do not discuss this issues here.
The above example defines the enabling rule for a specific department within a hospital. A trivial way of enforcing the same policy over all the departments would be replicating the rule for all departments. On the other hand, if the space is properly classified within the space hierarchy, we are able to write more compact and general policies.
Let us assume that the hospital is logically partitioned into different departments, e.g., Cardiology, Neurology, etc. Furthermore, let us assume that
Security managers may ask the access control system to enforce some specific one-time behavior, e.g. enabling/disabling a specific role, independently from the current context. Such possibility was provided in TRBAC by run-time requests.
A Run-time Request Expression is an expression
A run-time request expression can assume maximum priority. This means that, in principle, this type of expression can override other context-dependent prioritized event expressions. The sequence of run-time requests (labelled with their arrival time) is called Request Stream and is formalized as follows: A Request Stream (RQ) is an infinite sequence:
The ERBAC model does not include constraints. However, such a feature can be easily simulated using the ERBAC interaction with the environment and/or the use of triggers.
Separation of duties. Separation of Duty is a principle that is used to guarantee that no single person is responsible for the completion of a whole task. Such type of constraint can be easily simulated using triggers as follows. Suppose
For example, whenever a user tries to enable role
Threshold-based constraints. A second type of constraint allows the expression of conditions that depends on the cardinality of sets, e.g., of users. One example could be a constraint to describe the following access policy: No more than three guests can use the control panel in the secure room at the same time. In ERBAC we can use events for providing such type of constraints. We can assume that, whenever the maximum threshold is reached, the environment generates an event that is used to trigger the proper disabling rule in the REB. We can use the generateBy function in order to identify the last user who enabled the role and, thus, generated the event. In the above example, we can assume that there exists a role Use_Panel that allows guests to use the control panel. Furthermore, whenever “the number of guests using the control panel in the secure room is four”, the environment generates an event 4th_Guest. We can safely assume that the priority of event 4th_Guest is higher that the priority of AnyEvent. We can implement the above constraints by adding the following to the REB.
As it will be more clear in next section, whenever the event 4th_Guest is active, the second conditional event expression will be “more specific” than the former one and, thus, will prevail.
Simulation of role enabling and activation in ERBAC
Simulation of role enabling and activation in ERBAC
The GTRBAC model introduces a number of different constraints both on role enabling/assignment and activation. We will review the differences between GTRBAC and ERBAC and show how it is possible to simulate features of the former model in the latter.
Simulating role activation/deactivation. The GTRBAC model distinguishes role enabling and role activation. In particular in GTRBAC, and in its derived models, it is assumed that while role enabling is policy driven, role activation is executed by the user at her own discretion and it is, this, user driven. Such distinction does not exists in ERBAC because our goal is to completely automate the access policy process by eliminating explicit user requests or delegating to the environment the sensing of such requests. However, role enabling and activation can be simulated in ERBAC by using triggers and events. We stress that, given the simulation below, if required it is possible to extend the ERBAC syntax in order to provide such a distinction. In the spirit of ERBAC, we will assume that the user requests for activation and deactivation of a given role r can be intercepted by the events ActivateRole_r and DeactivateRole_r, respectively, both having the same priority of AnyEvent.3
As we will see in next section, if the events
The GTRBAC model introduces a number of different enabling and activation constraints. We will discuss each of them separately.
Periodicity constraints on role enabling. Periodicity constraint in GTRBAC “specify the exact intervals during which a role can be enabled or disabled” and, thus, correspond exactly to Temporal Conditions in ERBAC.
Duration constraints on role enabling. GTRBAC defines the role enabling events “enable/disable r” and the assignment events in the form
Duration constraints in GTRBAC are used to modify the amount of time in which a role can be enabled. Notice that the policy can specify a periodic expression in which the role might be enabled. The duration constraint can reduce the amount of time in which a role is actually enabled. We thus need to distinguish the policy driven role enabling from the actual role enabling request. In ERBAC we model the latter by means of an
Duration constraints can be defined both per-role, i.e., the constraint holds for a specific role, and per-user-role, i.e., the constraint holds for a specific user enabling/activating a specific role. In the following we show how to simulate per-role duration constraints. The same technique can be used to simulate per-user-role constraints by simply substituting “enable/disable r” with “enable/disable r for u”. GTRBAC specifies three possible syntax for duration constraints. In the following E denotes the simple event enable r. The same simulation idea, with the obvious modifications, can be applied in case E denotes the event disable r.
We first show how to simulate periodic duration constraints
enable r → disable r after
Rule 1 binds the actual enabling of role r to the role enabling request. Rule 2 triggers the disabling of role r after the maximum allowed duration
The duration constraints of type T2 are simpler than periodic ones since they are ‘one-shot’ constraints. Thus in order to obtain a simulation for this type of constraints it is sufficient to remove periodicity by (a) substituting in Rule 1
Finally, in order to simulate T3 constraints, it is sufficient to consider the constraint c itself as a role and manage its duration D by adding a guarding role
Temporal constraints on role activations. GTRBAC defines two types of temporal constraints on role activations. The first one, called the total active duration constraint, restricts the sum of all activation durations to be upper bounded by some value. The second one, called the maximum duration constraint, limits the maximum allowable duration of each activation of a role. The total active duration constraint can be simulated by associating to each role r an event TimeExceeded_r whose generation is used to trigger the disabling of role r. The maximum duration constraint can be simulated by combining the simulation of role activation and temporal constraint on role enabling.
Cardinality constraints on role activations. GTRBAC defines two types of cardinality constraints. The total number of activations and the maximum number of concurrent activations.
The total number of activation constraint forces a role r to be enabled (activated in the GTRBAC parlance) at most n times during a given period of time. It is possible to simulate such a constraint by using n guard roles
The maximum number of concurrent activation constraint. limits to n the number activation for a given role r that can be executed concurrently. Clearly, the difference between these types of constraint is that in the latter case every role disabling/deactivation should allow the possibility of enabling another instance of the same role. In order to simulate such a constraint in ERBAC, it is sufficient to add the following triggers to the ones shown above:
Priorities and conflict resolution
In complex Role Enabling Bases, a context may trigger conflicting event expressions. Before defining the semantics of the ERBAC model, we must specify how to resolve such conflicts. Recall that each event expression is associated with a priority and, thus, we stipulate that the event expressions with higher priority take precedence. However the system may activate two (or more) conflicting event expressions with the same priority simultaneously. In this case, we adopt the strategy denials take precedence. This strategy can be restated as follows: a role is enabled only if there exists no disabling expression for the same role whose priority is greater than or equal to one of the enabling expression.
Let S be a set of event expressions,
The set of event expressions in S that are not blocked by S will be denoted by
Thus, given a set of event expressions S, the system actually processes at every time t, the set of
Priorities, in general, do not suffice to remove all conflicts. The specificity of event expressions provides an additional criterion for conflict resolution that refines explicit priorities. A first, natural specificity criterion is based on spatial conditions.
Let
It is now possible to extend the concept of specificity to the conditional event expressions as follows:
Let
This criterion defines a partial order over conditional event expressions that might imply, depending on the context, the exclusion of some rules because their context is less specific than others. It is thus possible to define the set MostSpecific that, given a set S of rules, defines the subset of them that are most specific in S.
Let S be a set of conditional event expressions. We define the set
Let us see an immediate application of the ordering just defined. Assume the space hierarchy consists of the logical locations More specifically, It is interesting to observe the effects of ordering over the above rules in two specific contexts. Let us consider the triple Consider the case in which in state σ there are no visible events, i.e., Let us now consider the case in which
Now the overall behavior of the system can be formalized as follows: in every instant a subset of the conditional event expressions are satisfied by the current context. The most specific rules in this set identify the set of roles and run-time requests that generate the role enabling/disabling requests that the system will process to determine the set of roles that are enabled at the next time instant. Such behavior can be formalized by using the concept of system trace that describes the state of the system at each time point. A system trace is a pair
The sequence
Let If If for each state expression for each state expression for each event expression Let Global, General Events: Global, Personalized Events: Localized, General Events: Localized, Personalized Events:
then
The rationale behind rules 3(a) to 3(d) is the following. The effect of a conditional event expression can either be bound by the features of the event
Rule 3(b) is used to model personalized non-localized events. In this case the constraints posed by the personalized nature of the event, allows the prioritized event expression to affect only the users to which the event is addressed to. However, the spatial condition might further reduce such set of affected users by restricting it to contain only the ones that satisfy
Rule 3(c) models localized and general events. In this case, the set of users that are affected by the prioritized event expression is the one that meets the spatial conditions. Finally, the rule 3(d) manages personalized and localized events. In this case, the set of affected users are the ones for which the event has been generated for, whose position falls within the visibility range of the event and that satisfy the spatial condition.
At this point it is possible to define the behavior of the system introducing the concept of execution model. A system trace
Although most of the logic that binds the context to the system state has been limited to the concept of role enabling and disabling, the presence of role templates, role instances and parametrized privileges requires that in order to obtain the desired behaviour we need to redefine the
The U, S: sets of users and sessions as defined in P: set of parametrized privileges as defined in Definition 15;
Given the model just defined, an access request should be allowed only if there exists a parametrized privilege such that (a) its conditional expression is satisfied, and (b) the privilege is associated with a currently enabled role for the user who made the request. More formally, let
Conditional event expressions (Definition 18) allow the enabling/disabling of roles in response to environmental conditions. In particular, by using
Relaxing time constraints in response of events
Our approach allows the formulation of access policies that react to the exceptional events that may occur in the environment. Specifically, each reactive policy should consist of at least two apparently conflicting directives. A first one that models normal system behavior and a second one, that is used to describe specific anomalous events. The latter overrides the former.
For example, assume that in normal conditions an employee carries out her duties under some space-temporal conditions, e.g., a doctor in a hospital has access to the medical records of the patients in her department while she is in her office during the office hours. Such normal behavior has been already described in Examples 1, 2 and 3. Notice that, whenever the user is not in her department or she is there outside office hours, every access to patient records are implicitly forbidden.
On the other hand, such type of specification may be inadequate to address critical “unconventional” conditions. As a simple example, consider the case in which a doctor needs to access the medical records of a person having a heart attack while she is off-duty. In this case the event “heart attack” (assuming the patient is wearing a monitoring device that is able to recognize such a medical condition) can be used to relax the access policy to the patient medical record.
Let
In this case
The above rules enable, under normal conditions, permissions to doctors assigned to the cardiology department only during their WorkingHours and within the logical locations belonging to the department of cardiology. These limitations are overridden under specific medical conditions, so that a doctor can operate while she is off-duty.4
We will show a more complex example where space conditions are relaxed, too.
In this way we obtain a transparent management of permissions that, according to the minimum privilege principle, grants privileges only when they are strictly needed.
Also event localization supports the definition of special behavior in a flexible and compact way. Specifically, in some cases, it is desirable to modify the access policy only in contexts that are close to the event location. For example, in case of a medical emergency, it makes sense to modify the access policy of the doctors that are in the department in which the event occurred. At the same time, a critical event in a department should not influence the privileges of personnel in other departments.
Different notions of closeness can be considered; all of them rely upon the location in which the event occurred. Starting from this information, and depending on the information that are available on the structure of the surrounding space, finer access policies can be designed.
Consider the role template defined in Example 2 spanning over a number of departments. Let
If
Notice that, the “level of visibility”, i.e., the set of logical locations in which the event is visible, heavily depends on the information that the environment can generate. In the simplest case, the level of visibility, might be statically defined at the time of event definition. For example, if a specific device is physically located in a specific department, the administrator can associate a static list of logical locations in which the events generated by such device should be visible. Starting from this simple example, more complex situations can be easily imagined, e.g., mobile devices, multiple devices in different logical locations, and so forth. Clearly, complex situations require smarter/more complex definitions of the
A global event is, by definition, an event that is not localized. Such definition can be interpreted in two different ways. The first interpretation defines an event to be global if no information is known about the location in which it has been generated – which may happen, say, if the device that generated the event does not support localization. The second interpretation defines as global the events that affect or might affect the whole space. In this paper we consider the second notion of globality. Let us now consider the following simple example of global event.
Consider the case in which the a hospital has to face a Limited Access code due to some kind of disaster. In this case, the access to the hospital premises to guests is forbidden. We might define the following roles:
In this case, the REB might contain the following:
The first conditional event expression defines the normal operational behavior that allows guest to enter and exit the hospital during visiting hours. Whenever a LimitedAccess event is generated, independently from the current time, the Guest role is disabled, that is no more guest can enter the hospital. At the same time, the LimitedGuestAccess is enabled, allowing guests that might be in the hospital, to leave it.
We describe another example in a completely different context. The spatial constraints seem to be meaningful only in case we have to deal with “physical” objects. As we show in the next example, this is not really the case. Furthermore, we show that conditional event expressions can be used to limit the visibility of global events, by bounding the set of locations that can be actually reached.
Consider a web site that offers services to registered users only. The site policy allows read-write access to registered users during normal operations. On the other hand, it has to periodically execute some Account Check operations during which write-access should be forbidden. In order to reduce system unavailability, the administrator is able to execute such maintenance operation on a regional basis so as to exploit night hours and office closure.
This policy can be modelled using the event “AccountCheck” as a global-general event used to restrict the access to the users by defining the following roles:
Now, if
In the above example, the REB restricts the set of users to which the global event applies, based on the features of the user, i.e., she requires access from a place where it is currently night time. A different type of restriction might apply to features that are related to the resource being accessed. For example, we might partition the set of storage devices for a given service in different logical locations and limit the effect of global events by using such locations.
In the above examples we have implicitly assumed that events are general, i.e., in principle, they are visible to all users. The actual set of users whose policy might be modified in response of a given event generation is the one whose members meet the spatio-temporal conditions defined in the REB.
In our model, events may also be linked a priori to the set of users that may be affected by the event’s instantiations, i.e., events may be personalized. For example, we might modify Example 8, by defining a priori the set of users affected by the event AccountCheck. In other words, if AccountCheck is personalized, any instantiation of such an event will be visible only to the users defined by
Consider the case in which the generatedFor function can describe the list of “users requesting the service from a region during night time”. The REB of Example 8 can be rephrased as follows:
In the Example 9, the list of users that meet the spatio-temporal conditions defined by the policy in Example 8 is encapsulated in the definition of the generatedFor function. In general, this is not the case. Indeed, the set of users defined by the generatedFor function might be independent from the one defined by a spatio-temporal condition in the REB. Notice that it is possible to combine the effect of the event personalization and the spatio-temporal conditions in the REB in order to dynamically re-define the set of affected users as the intersection of the sets of users meeting both conditions. Let us assume that the event LimitedAccessHelp is a personalized event generated for all the users having specific qualifications, say doctors, paramedics etc. We might add to the REB the following rule:
In this case, the system should be able to generate two different events. The first one, LimitedAccess, described in Example 7, limits the set of users that can access the hospital. The second one, LimitedAccessHelp, should be generated in case the personnel realizes that they need “help” for managing the current situation. Such second event, would allow someone who is not employed by the hospital, but that has the proper qualifications, to temporarily gain the role of HelpGuest in order to fulfill the request. Such role, however, will be enabled only for the users that are either in or entering the ER department.
Until now we have described ways in which system generated events have been used to guide the behavior of users whenever some context-dependent condition is raised by the environment. On the other hand, if the environment is able to identify/manage events generated by users, such capability can be useful to transparently manage all the situations that are direct consequence of the actions of a specific user/set of users.
As a concrete example, consider disk quota management. It might be useful to define a policy stating that write privileges are revoked from users that exceed their quota. This policy is formalized by the following template:
Let
Technically, disk quota is an event generated by the system in response of the action of a user. However, for the sake of our presentation, this distinction is immaterial.
Let joe be a user and let
We stress that, although the event is generated by a specific user, its effects might also influence the behavior of other users. In the previous example the site policy might, in response to a QuotaExceeded event, forbid write access to every user on the specific device.
Clearly the conditions under which a role can be enabled or disabled may be completely unrelated. Such property is particularly useful whenever a process can be started under particular conditions but its execution does not require them to persist. Consider the following example. It is reasonable to assume that surgery can start only when all the specialized personnel is present. On the other hand, because of the criticality of such a process, it should not be possible to stop the process if, for some reason, some of the required conditions fails, (e.g., the principal surgeon faints). We can model such conditions by defining two events. The first one, SurgeryInProgress, is activated by the system as an effect of the actual start of the surgery. Clearly such an event is activated only after all the required conditions are met, i.e., all the required personnel entered the specific operating room, the supervisor is identified, etc. Notice that, SurgeryInProgress is bound to the execution of a process while it is not bound to the presence of a person with a specific role (the surgeon). A second event, NoResponsible, is defined as the situation in which no person that is able to assume responsibility is present in the operating room, e.g., the case in which no doctor is present in the room. We can use such events as follows:
Such a definition enables the role Assistant during the surgery and does not disable it in the unlucky case in which the principal surgeon faints, but other doctors are present in the room.
Notice that cascade role disabling could be alternatively implemented by means of the following rules:
However, with this formulation, the enabling/disabling of role Assistant depends only on the state transitions of role Surgeon and does not take the context into account. Such modelling would, thus, be too rigid and would not faithfully express the emergency handling policy.
Conditional event expression ordering
Priorities (and the corresponding ordering of conditional event expressions) support a layered and incremental formulation of policies, by means of general rules and suitable exceptions to those rules.
Event priority can be exploited to simplify and merge the access policies presented in Examples 7 and 10 as follows. Assume that the system is only able to generate a global/general LimitedAccess event. The REB can be written as follows:
Whenever a LimitedAccess event is generated, if a guest is not qualified to provide help, e.g., she did not provide any doctor or nurse credential, then the Guest role is disabled and the LimitedGuestAccess is enabled. allowing her to leave the hospital. On the other hand, if a guest has provided some credential that qualify her as a member of HelpGuest, two enabling rules apply, namely rule 3 and 4. However, since the priority associated to rule 4 is higher than the one in rule 3, only the former will be applied, by allowing the user to gain the privileges of HelpGuest role.
By using conditional event ordering, we can define tight policies. Consider, for example, the case of porters in hospitals. A porter has the role of moving patients and materials within an hospital. We can thus assume that, potentially, she has access to each area in the hospital. However, it is reasonable to limit the access of porters only to specific areas for the time needed to complete the transfer and only when a specific transfer has been requested.
Let us assume a spatial organization described by the following hierarchy over location types:
For efficiency reasons, we might think of restricting the area of a specific porter to a specific pavilion by using a role template as follows:
If we do assume the existence of an event
The effect of the first rule is to disable the instances of the template Porter bound to every pavilion in the hospital while the second one we enable the role instance related to the pavilion in which a transfer has been required.
Notice that, the two rules differ only in the event part and, thus, the second rule is more specific than the first one since
Another interesting case is the one related to the ordering of spatial conditions. In this case the system will tend to privilege rules that are referring to more specific spaces. In this way it is possible to specify policies for different logical layers corresponding to the different spatial organizations while being guaranteed, at the same time, that the system will always enforce the more specific one, i.e., the one that best fits the current user location.
An example of the above discussion can be done in the context of hospital-related policies, for the definition of the access policy to the operating room. Typically only a subset of the personnel working in a given Department has the qualifications to work in an operating room. For this reasons, the operating room represent an example of a (more specific) logical location that requires an access policy that is different from the more generic logical location to which it belongs to (e.g., Department, Pavilion, etc.).
For the sake of simplicity, let us assume that the following roles are the ones that can work in the operating room: surgeon, anesthetist and operating room nurse. The first two roles are assigned to doctors with a given specialization while the third one corresponds to a specialization for the nursing staff. This means that in the operating room a doctor or a nurse should loose their “generic” privileges and, if their role is enabled, acquire the new and more specific one related to the work they are supposed to do. Now, assume that
Then privileges can be assigned with the following policy:
In the above definition, rules 1–3 guarantee that every doctor within his own department has no more than all the necessary permissions needed to work in the department. The same policy is implemented for nursing staff by rules 4–5.
Rules 6–10 model the behavior of the system whenever the physical location of the user is within a more specific logical location, the OperatingRoom1. In this case, the system revokes the privileges that doctors and nurses had in the department (rules 6 and 9) and enables the more specific roles needed to work in the operating room (rules 7, 8 and 10).
The above strategy for policy definition has the following side effect. Although we adopt the “denials take precedence” conflict resolution policy, we can guarantee the correct enabling of roles because they are defined in “more specific” logical locations (OperatingRoom1) as opposed to the “more generic” Surgery. A second side effect is the disabling of roles for unqualified personnel entering the operating room. Indeed, if a nurse enters the operating room, her privileges are immediately revoked by rule 9. On the other hand, since she is not qualified to enable the role OperatingRoomNurse, such a role will not be enabled with the effect that the unqualified personnel will be in the operating room without any privilege.
In the previous sections we have considered the case in which event visibility is only related to the space hierarchy. In other words, whenever an event is defined, the administrator also defines the set of locations in which such an event is visible. There are scenarios, however, in which some event should reach a subset of users that are somehow “close” to the location where the event has been generated. In this paper we will only present a case in which, informally, two users are close if they are in the same logical location. We stress, however, that other notions of “closeness” might be defined as well.
We present a concrete application scenario. We consider the case in which patients carry mobile monitoring devices that are able to (a) store the medical records of the patient and (b) generate alerts in case some medical emergencies, e.g., heart attack. Clearly the protection of the patient’s medical record is a sensitive task that should be specified by a proper access policy. For example, we could assume that such information can be accessible only by the doctor who is responsible of the patient treatment and within some medical premises, e.g., doctor’s office or a department within a hospital. However, it is reasonable to assume that every patient would be willing to disclose her medical records to every doctor in case of real medical emergency. In other words, in case the patient is having a heart attack, independently from the place the patient is, release her medical records to whoever qualifies as a doctor that is close enough to save her.
In order to let whoever qualifies as a doctor to access such information, we need to provide such users with a minimal set of privileges that apply outside the logical location in which they usually operate. In other words, a user that belongs to the medical staff in some hospital will also be provided with a set of minimal privileges that can be used outside her home institution. This scenario assumes a federation of institutions that adopt a shared, global access policy such that a user identified as “surgeon” or “anesthetist” in the medical institution A is identified as
Among the permissions associated with the role
Let us assume
The policy that every institution should implement, must ensure the preservation of such a minimal role within the federation. We notice that, because of the ordering over rules in our model, the following set of rules yields the desired behavior of (a) assigning the proper role within the home institution and (b) assign the generic Doctor role outside.
ERBAC for usage control: Relationship with UCON
In [31] the authors introduces a meta-model that is able to describe different usage control models. Basic components in this meta-model are the following. The set of S of subjects consists of all the actors that can execute actions. Each action can be executed on one object belonging to the set O of objects. The set R of rights contains the privileges that allow a subject to execute an action on an object. The set A of authorization contains a number of predicates that are evaluated in order to decide whether or not a specific subject has the right to execute a given operation on a specific object. The set B of obligations consists of all predicates that verify the requirements a subject has to fulfill before or during an operation. Finally the set C of conditions is used to describe environmental or system-related factors. Both subjects and objects are characterized by attributes that can be used during the evaluation of predicates. Two basic ingredients in the UCON meta-model are attribute modifiability and continuity of decision. The former is used to describe the capability of an authorization system to deal with the dynamicity of subjects’ and/or objects’ attributes. The latter describes the capability of a model to keep monitoring the ‘granting conditions’ also after the actual permission has been granted. Each user request is always evaluated before the required permission is granted. So a systems might have pre-Authorization/oBligation/Condition, denoted by preA, preB or preC, respectively. Systems that keep monitoring the authorization process might have ongoing-Authorization/oBligation/Condition, denoted by onA, onB or onC, respectively. For example, continuous position monitoring in onA systems might be used to model mobility. The UCON meta-model is transaction-based. This means that each predicate is evaluated each time there is a user-request and the outcome of such predicates influences the authorization process.
The ERBAC model presented in this paper is able to manage role enabling/disabling transactions. Since our model is an extension of the RBAC model, there is a one-to-one mapping between the sets S, R, O in the UCON and the corresponding sets in ERBAC. in both frameworks subjects and objects are associated to attributes. ERBAC does not support attribute modification. The set C of conditions correspond in ERBAC to the set of environmentally generated information, that is, STECond. ERBAC does not support obligations at all. Since in the ERBAC model role enabling (resp., disabling) always implies role activation (resp., deactivation), our model is implicitly designed to provide continuity of decision. It is possible to classify ERBAC as an instance of the UCONonA,onC. ERBAC is an onA model since temporal and spatial conditions are continuously monitored in order to identify the “most appropriate” rule to be executed, cf., Examples 4 and 5. Finally ERBAC can be classified as an onC model to the extent that “events” are used to trigger enabling/disabling of roles, as in Examples 7 and 12.
Prototype implementation
We have implemented a prototype system that allows the specification and enforcement of ERBAC policies. It is available at [7]. Our prototype implementation is based on the XACML standard [25] for policy specification. We extended such a standard for allowing the specification of policies based on events. We have evaluated three different implementation of XACML, Sun’s XACML [25], XACML Enterprise [44] and XACML Light [45]. Among the available implementations, we have extended the open source java SUN’s implementation XACML [25] since it has a modular and easily extendible architecture. Furthermore, as noted in [42], Sun’s implementation, has a good trade-off between time needed to load policies and time needed to compute access decisions.
The XACML standard
OASIS Standard [25] introduces both a standard for policy specification and the description of an architecture that could be implemented to enforce such policies. Such an architecture consists of a number of elements, each devoted to a specific task. A central role is played by the Policy Decision Point (PDP) and the Policy Enforcement Point (PEP). The former receives access requests from the latter, decides whether or not the access should be granted and sends back the decision. The PEP is responsible for policy enforcement. It receives access requests from the users, forwards them to the PDP and implements its decisions. PDP requests and responses are specified using a canonical format, called the XACML Context. A specific component, the Context Handler is used to translate XACML contexts to/from the specific format supported by the PEP. Other elements in the architecture are the Policy Administration Point (PAP) that provides policies to the PDP, and the Policy Information Point (PIP) that is responsible for the evaluation of attributes, e.g., gathering state information or information from the environment.
Every access policy can be seen, informally, as a set of Rules. A Rule is the basic element in the language and it is defined by the triple (Target, Effect, Condition), where the Target identifies the circumstances to which the rule applies, the Effect specifies the outcome of the decision process and the Condition is a boolean expression over the set of attributes that can be used to further restrict the applicability of the rule. The Target consist of the 4-tuple (Subjects, Resources, Actions, Environment) that can be interpreted as the set of circumstances in which Subjects required the execution of some Actions on the Resources in a given Environment, where the latter element is represented by the set of attributes that are relevant for the decision process. The XACML defines four different values for Effect: Permit, Deny, NotApplicable, Indeterminate. The first two are used to permit or deny the required action. The effect of a rule is NotApplicable whenever the current request does not match the Target or the Condition. Finally the effect is Indeterminate whenever the rule evaluation requires the values of some attribute that is not currently available to the PDP.
XACML defines Policies as the set of rules that can be applied to a same Target, along with a specification of the algorithm for composing the effect of different rules when more than one is applicable (e.g., permit overrides deny). Furthermore, a policy might include a set of obligations, i.e., operations that should be enforced by the PEP in conjunction with the authorization decision. A Policy set is, informally, a set of policies. In [24] the OASIS consortium provides a profile for specifying RBAC policies using XACML. Roles and permissions specifications are obtained by two distinct Policy Sets. The Permission Policy Set (or PPS) is used to define a set of permission. Recall that a permission can be seen as a pair (operation, object). A PPS contains Policies and Rules in which the Target defines the Resources (objects) and the Actions (operations), and possibly other conditions that are used to restrict access. Such policies might also include references to other PPS associated with junior roles (allowing the inheritance of permissions). A RPS is a policy set associating the holder of a given role to the RPS containing the associated permissions. The Target of an RPS limits the set of subjects to which the role can be assigned. Finally a RPS can reference only a single PPS. A Role Assignment policy or policy set defines the association of users to roles. Notice that each PPS or RPS is a static object uniquely identified by a Uniform Resource Identifier (URI).
XACML extension
The XACML standard [25] defines a number of basic data types along with a number of functions that can be used to process such data. Clearly, in order to allow the formulation of policies based on STEConditions we needed to extend XACML. Such an extension consists both of new data types and functions that are needed to process the new types.
A contextual condition is defined by means of a triple containing a spatial condition, a temporal condition and an event condition.
For spatial conditions we need to be able to represent physical locations, logical locations and location types. Logical locations and location types can be represented as strings. A more complex representation is required for physical locations. In this case we need a way of representing coordinates and, more generally, geometrical shapes in two- and three-dimensional spaces. For these reasons we decided to used GeoXACML [27], an extension of the XACML standard by the OpenGIS Consortium [26,28,29]. GeoXACML can describe arbitrary geometric shapes starting from the following base types [29]: Point, LineString, Polygon, MultiPoint (a set of points), MultiLine (a set of LineString) and MultiPolygon (a collection of Polygon). The XACML schema is extended to allow the possibility of describing such new type of geometries by means of an extension of XML, known as Geography Markup Language (GML) [26].
As for temporal conditions we needed to introduce a new data type in order to represent periodic expressions. The pair
The representation of role templates in XACML using RPS and PPS is not immediate. The basic reason is that a role template is essentially a parametric role and, thus, it is not sufficient to define a new static object to represent it. Furthermore, a role instance is defined by assigning specific values to each role parameter. for this reason it is, in principle, impossible to define all possible role instance a priori. A second problem arises from the fact that the variables that are used to define parametrized privileges must be a subset of the variables of the role template that contains it. For this reason we extended the XACML grammar in order to identify the variables in the role instance definition in order to use them in the instantiation process.
XACML data type extension
XACML data type extension
XACML function extension
Our prototype implementation extends SUN’s XACML [41]. The main upgrades concern the PDP, i.e., the module that is responsible for policy decision. We have focussed our work on the issues related to context-dependent decisions, leaving out context-indepedent matters, e.g., triggers.
Space representation has been implemented by using the JTS [43] library. The implemented prototype supports the point and polygon types, that are necessary to define the physical location of an object and logical locations. Location types are represented by means of directed graph in which an edge between types A and B indicates that B is more specific than A. A Location Handler has been implemented in order to support the PDP in all decisions related to spatial conditions.
In order to make event management more flexible, we defined an interface that every event must implement. In other words, each event must be associated by the administrator to a name and a priority and, optionally, to the user who generated it, the user to whom the event is addressed to and the location in which the event occurred. Given such information the Event Handler will be able to support the PDP in the decision process.
Since our prototype is based on Sun’s XACML implementation, all the considerations reported in [42] still hold. In particular, running time is proportional to the size of the implemented policies measured as the total number of PolicySets and rules. What we are most interested in evaluating is the impact on running time of the new elements introduced in this paper. In particular, whenever more than one rule applies to the received access request, the PDP should compute the most specific context and apply the corresponding rule. in order to find the most specific rule the PDP needs to sort them according to (a) the event expression priority, (b) the event priority, and (c) spatial specificity, in this order. The first two are immediate, the third test requires a DFS over the graph representing location types. The probability that an access request involves a large number of rules based on the spatial condition is low. Indeed, the Target in the XACML rule is used to filter the rules in the policy. It is reasonable to assume that, for well designed policies, the average number of rules matching a given access request is low.
Another operation that could heavily affect the running time is the need to retrieve all logical locations that a given physical location belongs to (e.g., the user location). Notice that this operation is required in each STE-cond expression evaluation; it clearly depends on the number of logical locations and, thus, on the complexity of the spatial hierarchy the system has to manage. Furthermore, the higher the complexity of the polygon (i.e., the shape) that describes a logical location, the higher the actual time needed to check containment. A naive way of performing such an operation is checking whether a given point belongs to each logical location in the hierarchy. Such a strategy takes linear time in the (total) number of logical locations. In order to reduce the computational burden for this operation, we implemented the following strategy. Each logical location is identified by a set of polygons. For each logical location we consider the smallest rectangle (aligned to two given axis) that includes all its polygons and we identify the two intervals on the x and y axis corresponding to the rectangle sides. We construct two interval trees, an X-tree and a Y-tree, each including the coordinates of all the identified intervals on the corresponding axis. Whenever we need to recover the logical locations including a given physical location
Performance evaluation
In real-life scenarios the system’s response time clearly depends on a number of factors ranging from the access policy size to the efficiency of the devices that feed data to the PDP. In this paper we evaluate the overhead caused by policy rule evaluation alone (contingent aspects such as device response time and transmission overhead will not be considered).
A viable, efficient implementation of periodic rule triggering has already been discussed in the context of TRBAC [6]. Since the set of all temporal expressions in a REB has a periodic behavior, the approach adopted in [6] consists in materializing, at REB load time, an agenda that describes rule activation times for a single period (in terms of offsets from the period’s beginning). The agenda is used to program a cron daemon (at the beginning of each period) that triggers role enabling/disabling rules.
The same idea applies to our framework and suggest a simplification of context expressions that can be regarded as a pre-compilation of temporal conditions. Each context expression
Note that in our reference examples most context expressions are shaped like either
For this reason, our experiments deal with context expressions of this kind and focus on the overhead caused by the space expression S, that is, by event propagation across physical and logical locations, and by event overriding based on location specificity.
As stated before, our prototype at start-up loads and parses the files describing the access policy and the spatial hierarchy, building up their internal representation that will be kept in memory for evaluating access requests. This phase may be relatively expensive, but it takes place only once and thus we have not considered it in our scalability analysis.
The following experiments have been carried out on a Intel Core i7 processor at 1.7 GHz, equipped with 8 Gb of RAM and 512 Gb SSD, running Mac OSX v. 10.9.1.
The first experiment we have run is used to establish a baseline against which we measure the impact of the ERBAC model over the existing implementation. In order to do so, we need to design an experiment in which the decision process depends neither on the spatial hierarchy nor on the set of active events. For this reason we have considered policies defined over a single logical location, the whole space, with no active events. Given this naïve scenario, we have created
Evaluation time as function of number of policies and instances.
The results of these experiments, reported in Fig. 1, show that the average response time depends only on the number or templates in the policy since access requests are indexed by the role instance of the user requesting access. We notice that the average evaluation time is below 50 ms when the number of role templates is below
We have then evaluated the impact of space hierarchy and event management on the response time. For each experiment type, we have run different experiment sets with variable number of role templates and instances. For each set the behaviour of the response time is similar to the one shown in Fig. 1. For this reason, in the following graphs and tables, we only report the results obtained with
We started by evaluating the impact of the spatial hierarchy over system performance. We preliminarily recall that the access control decision for a given request depends on the most specific rule among all the rules that are applicable for the specific request. In order to do so, whenever a request is made, the system needs to recover all the logical locations that include the location P in which the request has been generated. As stated in Section 8.3, if n is the total number of locations and k is the number of locations containing P, the time needed to recover all the k locations of interest is
In order to evaluate the performance of the selection algorithm we have considered two different topologies for space hierarchy. The first one allows to have a number k of locations of interest that can range from 1 up to n. The second one is a quad-tree topology in which the number n of locations is exponential in the number k of locations of interest. The former topology stresses the algorithm as the number of locations intersecting the user location increases (this value coincides with k). The latter tests the scalability of the algorithm as the total number of locations increases while keeping the number of intersecting locations fixed.
Spatial hierarchies. (a) Linear hierarchy with n locations and
Accordingly, we have first considered a linear hierarchy consisting of two disjoint sets of square-shaped logical locations
The access requests are always generated by picking a point in
Such spatial hierarchy has been chosen because, as stated above, the evaluation of the most specific context requires (a) the computation of the smallest location in
The results of the experiments, reported in Fig. 3(a), show that, for the linear hierarchy, the average evaluation time is always below 20 ms, independently from the percentage of the intersecting locations. As expected, response time slightly increases as the number of locations increases. Fluctuations are mainly due to the reasonable hypothesis that access requests are generated by random users at random places.
Performance evaluation. (a) Response time for linear hierarchy without events. (b) Response time for linear hierarchy with events. (c) Response time for quadtree hierarchy. (d) Comparison between linear and tree hierarchies.
Subsequently, a different scenario has been evaluated, in which the space hierarchy is shaped like a quad-tree. More precisely, the hierarchy is defined recursively as follows. Each location at layer i, for
We have then considered the impact of events on the average evaluation time. In these experiments we have associated to each role template a different event. Furthermore, to each role we have associated a single activation rule. This last choice was made in order to measure only the impact of event management by avoiding any possible complication related to rule overriding. We have run several experiment sets by considering each time a different number of logical locations containing the request location. We have then populated the environment with a number of active events. Clearly, whenever the number of active events is greater than the number of templates, such extra events influence the system only in terms of performance while they cannot influence the access control behaviour. Our experimental evaluation shows that also in this case the percentage of intersecting locations does not influence the running time of the system. We report in Fig. 3(b) the average evaluation time only for a linear hierarchy with 50% of intersecting locations. Results for different percentages of intersecting locations are similar and thus omitted. As already anticipated in Section 8.3, the impact of event management in access control decision making is negligible. The results of the experiments are summarized in Table 7.
Summary of experiments
Summarizing, we designed and implemented an expressive, reactive policy framework. The underlying policy model, ERBAC, collects a number of features separately supported by previous models: It is event-driven, and supports spatiotemporal conditions and role templates (the latter are particularly important in e-health and hospital scenarios). Moreover, ERBAC introduces the notions of personalized and localized events that are useful in defining emergency handling policies. The policy model is equipped with formal syntax and semantics. Periodic time conditions are encoded as in TRBAC, while locations are classified along three dimensions: physical, logical, and the less common location types, that make it possible to associate a policy to all the locations with the same functionality (e.g. surgery room, or meeting room).
The expressiveness of the policy language has been tested through a variety of examples, to show its potential both in a hospital domain and, more generally, as a general purpose reactive policy framework. It turned out that ERBAC can naturally handle emergency-handling policies, by adapting and possibly relaxing access control constraints to face abnormal situations that require ad hoc decisions. Such capability is supported by a flexible overriding mechanism, based on explicit priorities as well as (implicit) specificity-based rule ordering. In this respect, our framework generalizes previous approaches, where emergency handling has been almost exclusively limited to handling application-generated exceptions, and hardware and communication failure [21] (that can be handled like other events in our model). Medical emergencies are handled in [22] through a fixed hierarchic procedures organized in three emergency levels; our policy language makes it possible to define more flexible emergency handling procedures.
ERBAC has been merged into XACML for two purposes: (i) supporting complex policy structuring and modularization through the policy composition constructs of XACML’s language; we stress that almost all the theoretical frameworks are “flat”, i.e. they do not support any policy structuring/composition constructs; (ii) testing the policy model in a standard architecture of industrial strength. These goals required extending XACML’s syntax and constructing a suitably enriched policy decision point (PDP), as explained in Section 8. As a result, we showed that a scalable working system can be obtained through a suitable integration of standard components and focussed specialized components, in a standard-preserving way.
The implementation made it possible to experimentally evaluate the performance of the policy language, and in particular the cost of evaluating complex conditions. We relied upon previous work on XACML to assess the feasibility of composition constructs (execution time exhibits a linear behavior in the worst case; careful policy structuring, through the TARGET tags, may further reduce the overhead). Then we focussed on spatiotemporal conditions. Temporal conditions can be reduced to atomic event handling. All the complexity is absorbed in the (static) pre-compilation of a cron agenda, and has virtually no impact at run time. So we focussed our scalability tests on spatial conditions.
Our experimental evaluation shows that the overhead caused by context-based, policy-rule evaluation is moderate and compatible with many real-world applications, even if our stress tests show that response time may increase non-linearly as the space hierarchy becomes more complicated.
Currently, ERBAC does not support event composition operators, such as sequence and co-occurrence. Such operators in principle make sense in pervasive computing environments and are an interesting subject for future extensions, although in our examples we felt no need for them, perhaps because event conditions are hosted by a prioritized policy rule language rich enough to simulate some event correlation conditions.
We conclude that the framework is a good starting point for designing a general purpose, reactive policy framework, because of its expressiveness and performance. We stress that this evidence could not have been gathered without carrying out the full design process, comprising the rich policy model selection, its assessment, implementation, and testing. The current system is ready for experimental deployment in realistic ubiquitous computing environments. Additional experiments should be targeted at potential hardware-related limitations, such as the overhead caused by limited device computing power and network/wireless transmission delay. In this context, device and transmission reliability may cause further issues; ERBAC’s ability of handling exceptional situations may prove to be suitable for mitigating this category of problems.
Footnotes
Glossary
| Function name/symbol | Meaning | Defined in |
| Set of physical locations | Section 4.1.2 | |
| Set of logical locations | Section 4.1.2 | |
| Set of location types | Section 4.1.2 | |
| Partial order over logical locations | Section 4.1.2 | |
| Partial order over location types | Definition 6 | |
| Temporal condition | Definition 10 | |
| Spatial condition | Definition 11 | |
| Event condition | Definition 12 | |
| Physical location in which an event is generated | Definition 9 | |
| Priority of an event | Definition 9 | |
| Set of prioritized event expressions at time t | Definition 25 | |
| Set of logical locations in which an event is visible | Definition 9 | |
| User who generated an event | Definition 9 | |
| Users to whom an event is addressed | Definition 9 | |
| Maps physical locations to logical ones | Definition 5 | |
| Maps locations type to logical locations | Definition 5 | |
| Maps logical locations to location types | Definition 5 | |
| Event expressions in S that are minimal w.r.t. < | Definition 24 | |
| Mutually compatible event expressions in S | Definition 21 | |
| Subset of REB whose conditions are met at t | Definition 26 | |
| Simple Event Expression: “enable/disable r [for u]” | Definition 16 | |
| Prioritized Event Expression: “p : enable/disable r [for u]” | Definition 16 | |
| Conditional event expression | Definition 18 | |
| < | Partial order defined over CEXP | Definition 23 |
| Denotes the SEXP conflicting with x | Definition 17 | |
| Set of intervals identified by the expression | Definition 3 | |
| Set of roles that are globally enabled at time t | Definition 25 | |
| Current time | Definition 3 | |
| The physical locations of a device | Definition 5 |