Location–Aware RBAC Based on Spatial Feature Models and Realistic Positioning

Abstract

The location of a mobile user presents valuable information when deriving access control decisions. Hence, several location–aware extensions to role–based access control (RBAC) exist in literature. However, these approaches do not consider positioning errors. This leads to unexpected security breaches, when the user’s ground truth differs from the reported location. Further, most approaches simply define a polygon as authorized zone and authorize when the reported position lies inside. To overcome these limitations, this paper presents a risk–optimal approach to RBAC. Position estimates are represented as probability distributions instead of points. Location constraints are assigned to RBAC elements and include cost functions for false positive and false negative decisions as well as feature models, which replace traditionally used polygons. Feature models describe for each location the likelihood that a specific feature can be observed. The evaluation shows that such risk–optimal RBAC outperforms risk–ignoring, polygon–based approaches. However, this risk–optimality is bought at the expense of a runtime highly increasing with the number of applied location constraints.

1 Introduction

Controlling the access of users or any subject to critical resources is a fundamental and security relevant problem. Basically, if access to specific resources is granted erroneously, typically severe costs arise. The same holds for erroneously denying access. In order to tackle this problem, access control models like role–based access control (RBAC) have been developed [16]. Here, a user is assigned several roles, each allowing for a set of permissions. In the next step, the user starts a RBAC session and selects a subset of assigned roles, which makes the attached permissions available for the duration of this session. During an open RBAC session on a mobile device, e.g., a smartphone or tablet computer, access requests to use permissions can be issued from any possible location in original RBAC. However, such access requests must not be granted if the user’s location lacks required features. For example, such a feature could be that the user resides on his company’s site if the permission is related to sensitive information. Also, the permission to remotely control a physical machine via a tablet computer could be limited to specific locations. For example, such remote control might be only considered safe if the user has a chance to reach the machine’s emergency switch in a predefined time span.

Therefore, many location–aware extensions to RBAC were proposed, which respect the user’s location when deciding about access requests. Most approaches constrain the availability of roles or permissions in RBAC policies to users within predefined geographical polygons, i.e., authorized zones. However, in practice, the enforcement of these extensions is complicated by positioning errors observed with real positioning systems. To the best of our knowledge, all location–aware RBAC extensions do not account for occurring risk attended by positioning errors. Furthermore, only polygons are adhered for extending RBAC policies, which makes it hard to model scenarios like the mentioned emergency switch.

In order to solve these gaps, this paper presents a location–aware extension of RBAC, which considers risk attended by positioning errors and comprises a generalization of existing polygon–based approaches. Instead of polygons, our location constraints assign feature models and cost functions to RBAC elements. A feature model describes for each location $x$ the probability that $x$ shows the required feature, for example to be capable to reach the emergency switch or to be on a company’s site. The cost values comprise both cost for false positives and false negatives. The former is assumed to occur if the constrained element is available for a RBAC session though the user’s location does not show the required feature. The latter occurs in the opposite case. Position estimates are reported as probability distributions rather than simple points. This allows to derive the probability that the user’s location shows a feature by integrating it over the feature model. This allows to derive both the risk, i.e., expected costs, of erroneously making the RBAC element available or unavailable respectively. Location constraints are enforced risk–based by taking the least risky choice.

The rest of this paper is structured as follows: Sect. 2 first discusses related work. Subsequently, Sect. 3 emphasizes the probabilistic nature of position estimates. Next, Sect. 4 presents the proposed RBAC extension in detail. Here, the basics of RBAC are revisited first in order to define the concept of location constraints based on feature models and cost values. A risk–based approach for enforcing location constraints on RBAC elements based on probabilistic position estimates is presented. Also, different ways to handle the sudden unavailability of RBAC elements in open sessions are identified. The effectiveness of the presented approach is evaluated in Sect. 5. Eventually, Sect. 6 concludes the paper.

2 Related Work

A detailed discussion of related work is given in this section. Discussed approaches stem from the research directions of spatio–temporal and risk–aware RBAC extensions, as well as risk–aware usage control.

Covington et al. introduced the concept of environmental roles, which are only active for predefined context states of the mobile user and need to be active in order to use certain permissions [5]. Hansen et al. constrain the permissions attached to a role based on the user’s location [6]. Ray et al. constrain for each RBAC session the allowed locations of users and objects [14]. During ongoing usage of the session, the user and objects are required to stay within the allowed locations. Chen et al. present ERBAC, a spatio–temporal RBAC model, which comes with different levels of restrictiveness and allows to constrain the availability of any RBAC element to specific spatio–temporal conditions [3]. Here, the availability of roles in the lifetime of an ongoing session depends on the spatio–temporal context. However, the semantic implications of reducing the set of initially active spatio–temporal roles is not considered. Furthermore, the dynamic assignment of permissions to roles complicates the construction and analysis of policies. Oleshchuck et al. [12] present GSRBAC, where permissions are also attached dynamically to roles based on the user’s and the accessed resource’s location. Again, implications of changed permission assignments in ongoing sessions are not discussed. Abdunabi et al. define a spatio–temporal RBAC model with trigger constraints, in order to control the availability of roles in ongoing sessions based on the user’s location [1]. Trigger constraints are defined in order to react persistently on spatio–temporal state changes of users, even after resources have been accessed. These approaches and according formal analysis do not account for positioning errors that are unavoidable with real positioning systems in practice. Risk stemming from those errors is not considered.

To respect occurring uncertainty, several non RBAC related approaches for spatio–temporal access control have been developed. Ardagna et al. define location predicates, for example to constrain access to resources to specific areas [2]. Their approach is not RBAC specific and location predicates are evaluated probabilistically based on confidence values. Thresholds were introduced to require a minimum confidence for a positive evaluation of a location predicate. Shin et al. describe the user location as a probability density function and integrate it over predefined authorized areas [17]. The resulting probability is compared to predefined thresholds, when authorization decisions are derived. However, the derivation of threshold values is left open.

Also several related risk–based approaches have been developed up to now. Ni et al. derive the risk of access requests based on fuzzy inference and fuzzy sets defined on the domains of the subject’s and the object’s sensitivity score [11]. Krautsevich et al. define a general approach for risk–analysis on mutable attributes in usage control policies in order to decide about ongoing sessions [7]. Here, focus lies on bridging the time until a fresh attribute value is provided by predictions with Markov chains. Similarly, Marcus et al. proposed an extension of usage control policies with trajectory constraints [9]. Salim et al. derive costs for each access request from an underlying RBAC policy [15]. A user is granted an issued access request as long as his previously assigned budget is sufficiently high to pay its cost. Chen et al. define a risk–aware RBAC extension and assign risk values to each user’s trustworthiness, degree of competence for each assigned role and the appropriateness of role–permission assignments [4]. For each access request, the involved risk values are combined to assess the overall risk. However, to the best of our knowledge, none of the existing approaches allows for location–aware RBAC while simultaneously respecting uncertainty of position estimates.

3 Characteristics of Imperfect Positioning Systems

All approaches to location–aware RBAC rely on positioning systems. In outdoor scenarios, GNSS based positioning systems like GPS are widely used. Indoor, where no line of sight to satellites exist, other techniques like, for example Wi–Fi fingerprinting are typically applied. Those approaches conduct measurements in order to derive a coordinate $\mu$ as the user’s estimated position. However, environmental and physical influences pertain these processes, which causes that $\mu$ deviates from the user’s real location [8]. The errors of GPS typically range from $9-11$ m while the errors of Wi–Fi fingerprinting are about $1-2$ m [10]. For each derived position estimate, it is uncertain where the real location actually lies. In order to model this uncertainty, a probability density function (pdf) $f_{\left( \mu , \varSigma \right) }(x)$ with the mean of $\mu$ and a scale parameter $\varSigma$ can be derived by an error estimator to describe the proximity of the real location to the position estimate $\mu$. Hence, a position estimate can be described as a tuple $\left( \mu , \varSigma \right)$. In case of Wi–Fi fingerprinting, those pdf can be modeled by Gaussians [10]. Here, the covariance matrix $\varSigma$ can be derived from singularities of the conducted measurement. In the following, those pdf will be used to derive risk–optimal authorization decisions.

4 The Probabilistic RBAC Policy

This Section first revisits the classical $\text {RBAC}$ Model and defines the proposed extension with location constraints. Next, the enforcement of applied location constraints is illustrated.

4.1 Revisiting the $\text {RBAC}$ Model

Role-based access control (RBAC) comprises four models for designing access control policies and was originally proposed by Sandhu et al. [16]. Basically, RBAC policies represent access control policies based on the following elements:

• U representing the set of users known to the system.

• R representing the defined roles.

• P comprising the permissions to be controlled. In particular, this describes that a specific action can be performed on a given object or resource.

In order to formalize access rights, three relations are defined:

• $\textit{UA} \subseteq U \times R$ represents user-role assignments

• $\textit{RP} \subseteq R \times P$ encapsulates role-permission-assignments

• $\textit{RH} \subseteq R \times R$ models a role hierarchy (only in $\text {RBAC}_1$ and $\text {RBAC}_3$)

In detail, UA assigns roles to users and RP assigns permissions to roles. Consequently, if a user $u$ is assigned a given role $r \in R$, all permissions related to $r$ are available to the user. The role hierarchy RH consists of tuples $(r,r')\in R\,\times \,R$, stating that role $r'$ is superior to $r$. In such cases, a user with an assigned role $r$ is granted all permissions assigned to $r$ or superior roles of $r$.

Chen et al. transferred this mechanism to a graph-based approach [3]. Here, a concrete policy is represented as a directed acyclic graph $\mathcal {P} = (V,E)$, with vertices $V = U \cup R \cup P$ consisting of the union of all defined sets and the edges $E= \textit{UA} \cup \textit{RP} \cup \textit{RH}$ consisting of all defined relations on vertices. A role $r$ is available for user $u$ if there exists an authorization–path (auth–path) $\langle u,\dots ,r \rangle$ in $\mathcal {P}$. The availability of roles is directly implied by the RBAC policy $\mathcal {P}$ and the static relations UA and RP in detail. In order to work with permissions and to attend his tasks, a user $u$ first needs to open an RBAC session $s$ [16]. In detail, an RBAC session is defined as a subset of roles available to user $u$. The roles in this subset are selected when the session is opened and may only comprise roles which are available to the user. If an available role $r$ is included in the session, $r$ is said to be activated. Without any formal extensions to RBAC, the set of available roles does not change with time. Hence, a session in original RBAC stays valid until a user quits it manually.

Fig. 1.

Illustration of different phases of sessions (adapted from [13]).

A reference monitor for RBAC policies can be realized by usage control policies like UCON, originally proposed by Park et al. [13]. For a given ongoing session $s$, where permissions $p_0,\dots ,p_n$ are currently used, this is depicted schematically in Fig. 1. When applied to RBAC, UCON basically divides the lifetime of each open session or used permission in three parts: pre–authorization, ongoing usage and post–authorization. Consequently, permissions are always used in the context of an ongoing session in the original RBAC.

4.2 Syntactic Definition of Location Constraints

This Section describes the syntactic extension of $\text {RBAC}$ policies with location constraints. The approach is presented top–down: First, feature models for locations and the concept of cost functions are defined. Based on these building blocks, the formal definition of location constraints is given.

Feature Models for Locations. An element $e$ of an RBAC policy, for example a role, can be considered location sensitive, if the user’s current location provides a valid source to decide if $e$ shall be available in his current session. In detail, the requirement that the user is at a certain location can be considered reasonable if the location has intrinsic features that naturally fit to the element $e$. For example, the activation of a role employee may only be reasonable if the user’s location has the feature that it lies on the companies site. Furthermore, the operation of a physical machine via a mobile device in a factory may only be granted if the user’s location has the feature that it allows to reach the machine’s emergency switch in a given time. This may be required by legal safety and security restrictions. Often, it is not clear where to draw the borders of such areas that show a required feature. Thus, instead of defining according polygons for features, a Boolean random variable $F_e$ is defined to describe the presence of a required feature $F_e$. In order to describe the probability that a required feature $F_e$ is present at a given location $x$, a feature model is defined:

Definition 1

(Feature Model). A feature model is defined as a conditional probability distribution ${\varvec{P}}(\textit{F}_e | X)$ that describes for each location $x \in X$ the probability that location $x$ has the required feature $F_e$.

Note, that probability distributions over a random variable $F$ are denoted $\mathbf P (F)$. Single probabilities for $F = f$ are denoted $\text {P}(f)$. In the following, feature models are used as a generalization of the hitherto used polygons that describe authorized zones. This concept is illustrated by three distinct examples.

Example 1

In the first example, an office room was identified to possess the required features of a location sensitive role employee. In such cases, the model $\mathbf P (\textit{F}_\mathtt{employee } | X)$ represents a distribution over the office $\mathcal {L}$ (a closed polygon) with sharp bounds on its walls. Clearly, all points $\mathbf {x} \in \mathcal {L}$ show the feature of being within the according office contrary to points outside $\mathcal {L}$. This leads to the following definition of $\text {P}(\textit{F}_\mathtt{employee } | X)$:

$$\begin{aligned} \text {P}(\textit{f}_\mathtt{employee } | x) =\left\{ \begin{array}{cl} 1, &{} \text{ iff } \mathbf {x} \in \mathcal {L} \\ 0, &{} \text{ otherwise } \end{array}\right. \end{aligned}$$

(1)

Note, this feature model is a generalization of approaches to location–based access control that use point in polygon tests to decide about authorizations.

When the required feature is only present at a given location $x$ with a certain probability, the definition of polygons for existing approaches is a hard task.

Example 2

Assume a building, where a worker in role controller remotely controls a physical machine using his mobile device. Assume that legal constraints prescribe that during mobile usage of permissions assigned to role controller, the worker needs to be able to physically reach the machine’s emergency switch within a time of $t$ seconds. This property is modeled as the feature of locations for role controller. Consequently, given a mobility model for human movement, the probability of reaching the emergency switch can be modeled for each point on a building plan or the map in general. The according feature model shows a smooth decrease of $\text {P}(\textit{f}_{\mathtt{controller }} | x)$ with larger distances of $x$ to the emergency switch and is thus called floating feature model in the following.

Fig. 2.

Distances (m) to emergency switch.

Fig. 3.

Feature model with 50 % polygon.

Floating models can be created in two steps. First, the specific point that a user has to reach within time needs to be identified on the building plan. For example, this point may represent the above–mentioned physical machine’s emergency switch that a mobile user has to reach. Next, the distance to the specific point is computed for all other points on the map. This is illustrated in Fig. 2. In order to derive a feature model from the distance model, a minimum required velocity $v_{\text {min}}$ is computed for each point by dividing the point’s distance with the prescribed time span. Finally, the probability to reach the specific point in time can be obtained from the survival function of a cumulative distribution function for the human walking speeds. In our case, a Gaussian with a mean at $4$ $\frac{\text {km}}{\text {h}}$ and a standard deviation of $2$ $\frac{\text {km}}{\text {h}}$ is chosen. The feature model derived from the distance model of Fig. 2 with a time limit of $6$ s is depicted in Fig. 3. Here, also a polygon is depicted that contains all points with a feature probability larger than $0.5$. This polygon might have been chosen in classical point in polygon approaches to location–based access control to approximate the desired behavior. Clearly, such floating feature models do not respect that humans need to slow down when walking around corners nor a minimum distance to walls. However, it though represents a good approximation of the probability to reach the specific point in time.

At last, not only safety constraints can be adhered for deriving $\mathbf P (\textit{F}_e | X)$ but also security considerations.

Example 3

Assume the site of a company with an office $\mathcal {L}$ protected by physical entrance control, e.g., locked doors with corresponding keys or RFID cards. The set of persons, which are able to enter a location $x$ is a feature of each location. If a user’s mobile device was stolen and used to activate a role $r$ within $\mathcal {L}$, the theft also needs to possess that key card. Hence, a feature model can be defined that describes the Boolean feature, that the mobile device’s current user stems from the role’s assigned users $U'\subseteq U$. It is defined as the quotient of users $U'$ assigned to $r$ and all persons $\textit{Persons}$, which may reside at point $\mathbf {x}$:

$$\begin{aligned} \text {P}(\textit{f}_r | X = \mathbf {x}) = \frac{\left| \left\{ u \in U \, | \, (u,r) \in \textit{UA} \wedge \mathtt{has\_entrance }(u,\mathbf {x})\right\} \right| }{\left| \left\{ p \in \textit{Persons} \, | \, \mathtt{has\_entrance }(p,\mathbf {x}) \right\} \right| } \end{aligned}$$

(2)

with $U' \subseteq U \subseteq \textit{Persons}$. Here, the predicate has_entrance denotes if a user or a real–world person has the necessary keys to enter and reside at a location $x$.

Based on a feature model $\text {P}(\textit{f}_e | X = \mathbf {x})$ and a position estimate of a user $u$ at time $t$, it can be derived how likely the user’s current ground truth location satisfies the features required by the feature model. In detail, the distribution of $\mathbf P (\textit{F}_e)$ is computed by marginalizing the feature model over the pdf $f_{\left( \mu , \varSigma \right) }(x)$ of user $u$’s position estimate $\left( \mu , \varSigma \right)$:

$$\begin{aligned} \text {P}(\textit{f}_e) = \int _{X} \text {P}(\textit{f}_e | X = x ) \cdot f_{\left( \mu , \varSigma \right) }(x) \,\mathrm {d}x \end{aligned}$$

(3)

Hence, Eq. (3) allows to derive the probability $\text {P}(\textit{f}_e)$ that the user’s current ground truth, i.e., real–world position showed the feature $F_e$ at the moment his position estimate ${\left( \mu , \varSigma \right) }$ was taken.

Cost Values for RBAC Elements. Due to the probabilistic position estimates, a definitive proposition if the user’s ground truth position satisfies the feature required by an element $e$ is not possible. Only a probability can be derived that a user’s ground truth location satisfies the feature at time $t$. However, in the following it is assumed that costs arise if an element $e$ is made available though the user’s location does not show the feature required by $e$. Thus, each location sensitive element $e$ is assigned two cost functions $c_{\textit{fp}}$ and $c_{\textit{fn}}$ beneath its feature model. The cost $c_{\textit{fn}}$ describes the cost that arises if a user is not allowed by the policy to employ the location sensitive element $e$ in his session though his ground truth location satisfies the required feature. Contrary, cost of $c_{\textit{fp}}$ arise if a user is allowed to employ the location sensitive element $e$ in his session though his ground truth location does not show the required feature.

Extending RBAC with Location Constraints. Based on the concept of feature models and cost functions, location constraints can be defined for single elements of an RBAC policy. In the original RBAC model, a user $u$ is granted all permissions that are reachable via an auth–path that only passes roles in $u$’s open session $s$. In order to keep this semantic, location constraints must not be applied to RBAC elements $e$ with $e \in \textit{RP}$ or $e \in P$. Formally, a location constraint assigns a feature model and two cost values to an RBAC element:

Definition 2

(Location Constraint). A Location constraint for an RBAC element $e \in U \cup \textit{UA} \cup \textit{RH} \cup R$ is defined as a 3–tuple $\left( {\varvec{P}}(\textit{F}_e | X), c_{\textit{fp}}^e , c_{\textit{fn}}^e \right)$, consisting of a feature model for a feature $F$ and costs $c_{\textit{fp}}$ for false positives and $c_{\textit{fn}}$ for false negatives.

A simple example of a location constrained RBAC policy is depicted in Fig. 4. Here, the assigned location constraints of the auth–path $\langle u, r_1, \dots , r_n \rangle$ require the features $F_{r_1},\dots ,F_{r_n}$ to be true at the user’s ground truth location. In order to finally decide if a given RBAC element $e$ shall be available for a user, location constraints restrict the existence of auth–paths based on the user’s current position estimate. This enforcement is presented in the next section.

Fig. 4.

Evaluation of the auth–path $\langle u, r_1, \dots , r_n \rangle$. Assigned location constraints are associated to the according role by an arrow.

4.3 Enforcement of Location Constraints

In this section, the enforcement of location constraints is presented. The authorization decisions are derived and enforced by a reference monitor based on the original RBAC policy and its assigned location constraints. The reference monitor is provided a stream of trustworthy position estimates of each user with an ongoing session by a trustworthy and tamper–proof location provider. The frequency of reported position estimates needs to be high in order to minimize time gaps of uncertainty about the user’s position. However, the tamper–proof and high frequent measurement of position estimates is not subject of this paper.

Similar to original RBAC, each user first has to activate roles when starting a session $s$ in a pre–authorization phase. Here, each role $r$ can only be activated for $s$ when there exists an auth–path $\langle u, \dots , r \rangle$ in the original unconstrained RBAC policy $\mathcal {P}=\left( V,E \right)$. The location constraints are enforced in the next step by mapping the original session $s$ to a constrained session $s'$ with $s' \subseteq s$. That way, the original RBAC authorization semantic can be preserved, by substituting the original $s$ by $s'$ when searching for auth–paths. During ongoing usage of the session, this procedure is repeated by the reference monitor for each position estimate reported by the location provider. Consequently, a user $u$ is only allowed to use a permission $p$ in his ongoing session $s$ if the roles in the according constrained session $s'$ allow an auth–path $\langle u, \dots , p \rangle$ such that all passed roles are contained in $s'$. This is illustrated by Algorithm 1. The next section finally presents the handling of location constraint violations by the procedures handle_session_violation and handle_permission_violation. The rest of this section describes the procedure update_session_roles. This procedure derives the constrained session $s'$ by searching for an auth–path to each role $r \in s$. If an auth–path is found, $r$ is also included in the constrained session $s'$. By enforcing the assigned location constraints, originally possible auth–paths can be deactivated, which can lead to the fact that $s'$ is only a subset of $s$.The requesting user has a ground truth state, which means that each feature required by any of the auth–path’s location constraints is either true or false at his ground truth location at the moment of the request. The likelihood that a single feature is true at a location $x$ is described by its according feature model, as discussed above. When enforcing the location constraints, each auth–path may happen to be deactivated. This may happen though some of the features required by the auth–path’s location constraints are true at the user’s ground truth location. In that case, the false negative cost of those location constraints are assumed to arise in the real world. Similarly, the opposite holds if the auth–path stays active though some of the features required by its location constraints are currently false at the user’s ground truth location. In such cases, their according false positive cost will arise. Hence, the arising cost when activating or deactivating the auth–path depend on the user’s ground truth state. In the optimal case, the user is in a ground truth state where either all features are true and the auth–path stays active or vice versa, as consequently no costs arise.

When operating the location constrained RBAC policy, such arising costs need to be minimized. Thus, all decisions about deactivating auth–paths have to be risk–optimal. Therefore, the expected cost of both deactivating the auth–path or leaving it active need to be examined. That decision with the least expected cost is finally chosen.

If the auth–path is assigned $n$ location constraints, each required feature $F_1,\dots ,F_n$ is either true or false in ground truth. Hence, there exist $2^n$ possible ground truth states $\sigma _1,\dots ,\sigma _{2^n}$. Formally, each $\sigma _i$ is a $n$–tuple assigning each feature $F_1,\dots ,F_n$ a Boolean value. Assume $\pi (\sigma _i)$ is the probability that a state $\sigma _i$ reflects the user’s current ground truth state. Further let $c_{\textit{fp}}(\sigma _i)$ denote the sum of false positive cost $c_{\textit{fp}}$ of those location constraints assigned to the auth–path, whose required feature is false in $\sigma _i$. Similarly, $c_{\textit{fn}}(\sigma _i)$ is the sum of false negative cost $c_{\textit{fn}}$ of those location constraints assigned to the auth–path, whose required feature is true in $\sigma _i$. This allows to derive the expected cost, i.e., risk, for both deactivating the auth–path or leaving it active:

$$\begin{aligned} \mathtt{risk\_deactivate }= & {} \frac{1}{2^n} \cdot \sum _{i=1}^{2^n} \left( \pi (\sigma _i) \cdot c_{\textit{fn}}(\sigma _i) \right) \end{aligned}$$

(4)

$$\begin{aligned} \mathtt{risk\_activate }= & {} \frac{1}{2^n} \cdot \sum _{i=1}^{2^n} \left( \pi (\sigma _i) \cdot c_{\textit{fp}}(\sigma _i) \right) \end{aligned}$$

(5)

In order to operate the location constrained RBAC policy risk–optimal, in each case that decision is chosen, that has the least expected cost:

$$\begin{aligned} \mathtt{deactivate } \Leftrightarrow \mathtt{risk\_deactivate } < \mathtt{risk\_activate } \end{aligned}$$

(6)

In order to evaluate Eqs. (4) and (5), the likelihood $\pi (\sigma _i)$ that $\sigma _i$ reflects the user’s current ground truth state needs to be computed. Therefore, the state’s joint feature model is derived first:

$$\begin{aligned} \forall x \in X: \ \text {P}\left( \bigwedge _{j=1}^{n} F_j = {\sigma _i}_j | x \right) = \prod _{j=1}^{n} \text {P}\left( F_j = {\sigma _i}_j |x \right) \end{aligned}$$

(7)

Here, the index $j$ to a ground truth state $\sigma _i$ references the Boolean value of feature $F_j$ in this state. To clarify things, assume $\sigma _1 = \left( \mathtt{true }, \mathtt{false } \right)$. The corresponding joint feature model $\text {P}\left( F_1 = \mathtt{true } \wedge F_2 = \mathtt{false } \right| x)$ computes as $\text {P}\left( F_1 = \mathtt{true } | x \right) \cdot \text {P}\left( F_2 = \mathtt{false } | x \right)$ for all possible locations $x \in X$.

Finally, $\pi (\sigma _i)$ is obtained by marginalizing out the parameter $X$ using the Gaussian pdf for the user’s position estimate $\left( \mu , \varSigma \right)$:

$$\begin{aligned} \pi \left( \sigma _i\right) = \text {P}\left( \bigwedge _{j=1}^{n} F_j = {\sigma _i}_j \right) = \int _{X} \text {P}\left( \bigwedge _{j=1}^{n} F_j = {\sigma _i}_j |X=x\right) \cdot f_{\left( \mu ,\varSigma \right) } (x)\ \text {d} x \end{aligned}$$

(8)

In order to derive the complete constrained session $s'$, this methodology needs to be repeated for each role activated in the original session $s$. The final definition of the procedure update_session_roles is presented in Algorithm 2.

4.4 Handling Location Constraint Violations

The enforcement of location constraints in an ongoing session produces constrained sessions with probably fewer available permissions, as seen above in Sect. 4.2. In detail, an ongoing session $s$ is defined to be violated if not all roles from $s$ are included in the according constrained session $s'$. Furthermore, if there is ongoing usage of a permission $p$ in progress though no auth–path to $p$ is allowed by $s'$, the permission is considered violated. Both cases need to be handled by the reference monitor. Therefore, Algorithm 1 called the procedures handle_session_violation and handle_permission_violation. This section shows possible realizations of these handlers and discusses their implication on the reference monitor’s semantic.

Both violation handlers can be realized by three basic reactions: continue, pause and stop. Thus, in case of session violations, sessions are either continued, paused (blocked from any user interaction) or stopped (terminated). The same holds for permission violations. When designing a reference monitor, appropriate implementations for both violation handlers need to be given. All possible combinations of these violation handlers span a $3\,\times \,3$ matrix, which is depicted in Fig. 5. Note, the reaction of handle_session_violation is abbreviated with $h_s$ and similarly the reaction of handle_permission_violation is abbreviated with $h_p$. Let $\prec$ be a total ordering on the set of reactions with $\textit{continue} \prec \textit{pause} \prec \textit{stop}$. Let $\sim$ denote similar restrictiveness of two reactions. These combinations form three distinct and semantically different categories:

Fig. 5.

Models and categories (equal color) resulting from handler combinations.

• 1. The reaction $h_s$ on the session is more restrictive than on the ongoing used permission $h_p$, i.e., $h_p \prec h_s$.

• 2. The reaction $h_s$ on the session and the reaction $h_p$ on the ongoing used permission are both equally restrictive, i.e., $h_p \sim h_s$.

• 3. The reaction $h_s$ on the session is less restrictive than $h_p$, which is applied to the ongoing used permission, i.e., $h_s \prec h_p$.

In order to clarify the different semantics, an example is given for each of the presented categories. From category $1$, Model 3 with $(h_s = \textit{stop}, h_p = \textit{continue})$ is particularly useful, if the applied location constraints shall only be enforced when new ongoing permissions are started. For example, a permission to remotely start a physical machine in a factory could require the worker to stand next to the machine when he starts it, in order to check if it is equipped with enough raw material. Hence, new permissions must not be started after a constraint violation but ongoing permissions may be completed. In category $2$, Model 9 with $(h_s = \textit{stop}, h_p = \textit{stop})$ is the most restrictive model. It is considered particularly useful, if the set of active roles in an ongoing session makes no sense anymore after the user changed to locations that lack required features.

For example, assume a role in a clinical environment for users, which are within a disinfected area and are considered hygienic. After leaving the disinfected area, the hygienic status of the user is unknown until he passes the procedure of disinfection again. Thus, a new session with an initial checking of the availability of selected roles needs to be started here. A special case is Model 1, which is the least restrictive within category $2$ and neither the status of the session nor any ongoing used permission is affected by unjustified context. This annihilates the effect of any defined location constraints and hence behaves like original RBAC. Thus, sessions are only terminated by the user himself in that case. Within category $3$, Model 8 with $(h_s = \textit{pause}, h_p = \textit{stop})$ is useful, if the result of a used permission is not trustworthy if one of the session’s roles was temporarily unavailable due to location constraint violations. Finally, as shown by the discussed examples, the combination of violation handlers needs to be carefully selected by the policy designer as it is highly application specific.

5 Evaluation

The evaluation was conducted in the office environment depicted in Figs. 2 and 3 with feature models based on the underlying building plan. Two types of feature models were defined, bounded and floating feature models. Bounded feature models were inspired by Examples 1 and 3. They model a feature’s occurrence with a probability of $p \in \left[ 0.5, 1.0 \right]$ within the underlying room and $0$ outside of it. Thus, the occurrence of a feature within the underlying room is the most likely case. Additionally, floating feature models were defined based on the idea of Example 2, where the user needs to reach a specific point within a predefined time span. Overall, $40$ feature models with random specific points within the depicted rooms were created. The underlying time limits were chosen uniformly distributed from the interval $\left[ 3\,\text {s}, 15\,\text {s} \right]$. Additionally, $40$ bounded feature models were created for the depicted rooms. Overall, $8000$ possible location constrained auth–paths were simulated by randomly combining at least $2$ feature models. In order to keep the simulated auth–paths satisfiable, in each case one of the rooms from Figs. 2 and 3 was chosen first. Next, a random number of feature models that are defined on that room or that have their specific point in that room were selected. For each simulated auth–path, the single location constraints were all assigned the same value of $c_{\textit{fp}}$. Similarly, the value of $c_{\textit{fn}}$ was the same for each location constraint on that auth–path. The effectiveness of the approach was compared to classical approaches that use point in polygon tests. In order to obtain a polygon for each of the $8000$ generated combinations of feature models, in each case a polygon was extracted. This polygon was extracted from the joint feature model where all features are true. The boundary of the polygon is the $50$ % contour line such that the required features are true more likely than $50$ % for each point within. Figure 3 shows such a polygon.

Fig. 6.

Expected savings in percent.

Fig. 7.

Runtime for both approaches.

As underlying positioning system, SMARTPOS was chosen [10]. It is based on Wi–Fi fingerprinting and uses a kNN approach to estimate the user’s position $\mu$ and an error estimate Gaussian with a covariance matrix $\varSigma$. A radio map of $816$ Wi–Fi signal fingerprints was collected for the area depicted in Figs. 2 and 3 along with a large set of test samples to get position estimates. The cost of wrong auth–path (de)activations were recorded for the presented approach and the point in polygon based approaches and put in relation. The expected savings from running the presented approach are depicted in Fig. 6. Clearly, the benefit from running the risk–optimal approach rises with the cost stemming from false decisions. Consequently, the presented approach is especially useful for those policies that have location constraints with very different values for false positive and false negative costs. Also the runtime of both approaches was compared. In detail, the extraction of a $50$ % polygon from a feature model was compared to the derivation of all ground truth states’ joint feature models. The evaluation was conducted on a Intel Xeon X5650 CPU with $2.67$ GHz and $8$ GB RAM with Python $2.7.6$ and Numpy $1.7.0$. The results are shown in Fig. 7. Clearly, the risk–optimality and implied expected savings are at the expense of runtime, which increases exponentially with the number of location constraints on an auth–path. Thus, the risk–based approach is only practical for auth–paths with a very limited number of assigned location constraints. However, most auth–paths in an RBAC policy have a common prefix due to the policy’s tree structure. This allows to partially precompute joint feature models for such prefixes. For a final auth–path only the missing features need to be included.

6 Conclusion and Future Work

This paper has presented an approach for location–aware RBAC that restricts the set of available roles based on the user’s location. This allows to keep the original authorization semantic of RBAC. The concept is realized by assigning location constraints to policy elements and enforcing them risk–optimal. Location constraints can be assigned to any RBAC element except permissions and permission assignments. They consist of three parts. A feature model and cost functions for false positives and false negatives. The feature model is highly specific to the RBAC element that a constraint is assigned to. It describes for each location the probability that a feature that is required for enabling this RBAC element is present. For example, such features are the probability to reach an emergency switch within a predefined time span or the fact that a location is on the company’s site. The cost functions describe monetary costs occurring from making the constrained element available though the user’s location lacks the required feature or vice versa. Position estimates are reported as probability distributions and used to estimate the features that are present at the user’s location by integrating it over the feature model. This allows to derive both the risk, i.e., expected cost, of erroneously making the RBAC element available or unavailable respectively. Location constraints are enforced risk–based by taking the least risky choice. However, existing approaches to location–aware RBAC do not account for uncertainty of position estimates and represent them as a point. Further, location constraints in literature are based on polygons to represent authorized zones. Here, point in polygon tests decide about an element’s availability instead of taking the least risky choice. The conducted evaluation showed that the presented approach can significantly reduce occurring cost from false authorization decisions. In detail, the expected savings compared to existing approaches were shown to highly depend on the ratio of false positive to false negative costs. This implies, that this approach is most effective if, for example, the false positive cost are high compared to the false negative cost. However, the evaluation also showed that such risk–optimal RBAC is only feasible when a limited number of location constraints is assigned to each auth–path. To conclude, the presented approach is risk–optimal and allows for improved expressiveness of location constraints compared to hitherto used polygons. Furthermore, positioning errors are respected, which is important if those errors are not negligible, like in many realistic scenarios. We argue that the presented approach helps to provide a more reliable and cost efficient foundation for integrating mobile devices in working environments, for example in manufacturing processes. Future work is seen in providing trustworthy location measurements. Also, the user’s location demands a risk–optimal interpolation between two reported position estimates.