AN ACCESS-CONTROL MODEL FOR MOBILE COMPUTING

WITH SPATIAL CONSTRAINTS

Location-aware Role-based Access Control with a Method for Consistency Checks

Michael Decker

Institute AIFB, University of Karlsruhe (TH), Englerstr. 11, 76 128 Karlsruhe, Germany

Keywords:

Mobile Information Systems, Access Control, Location-based Services, Mobile Security.

Abstract:

Some of the most salient challenges that come along with the employment of mobile information systems stem

from security issues: portable devices like PDAs, smartphones and notebooks easily get stolen or lost and

wireless data transmission could be eavesdropped, so that unauthorized individuals gain access to conﬁdential

resources. One approach to tackle these problems is location-aware access control, i.e. based on knowledge

about the user’s position the information system can decide if access to a resource should be granted or not.

For example a nurse using a PDA should only be allowed to access conﬁdential patient data while staying on

the premises of the hospital. In our article we present a data model for location-aware access control based

on the concepts of roles. Using our model it is possible to assign location restrictions to several entities, e.g.

to users, to roles or permissions. We also propose a method to analyze the consistency of spatial constraints

expressed by an instance of our model.

1 INTRODUCTION

Nowadays it is possible to build portable computers

like PDAs and smartphones which are more power-

ful than stationary systems were a few years ago. At

the same time technologies for wireless data commu-

nication like GPRS, WiFi or UMTS were developed

and are nowadays widely available. Based on these

two technologies mobile information systems (MIS)

can be realized to make computer support available

almost anywhere and anytime. These MIS have a

great potential for many novel application scenarios,

especially with regard to support mobile workers. But

the utilization of mobile technologies comes along

with serious security challenges, because due to their

portability and small size mobile devices easily get

stolen or lost. If unauthorized individuals get into the

possession of a mobile device they can gain access to

conﬁdential resources (e.g. health records, telephone

numbers of board members, ﬁnancial data).

In our work we employ the concept of location-

aware access control to address this problem ﬁeld.

The basic idea is that for the decision wether a par-

ticular user is allowed to access a given resource the

current location of the mobile device is regarded. For

example the access to the customer database using a

mobile device should only be granted if the mobile

user just stays on the premises of the company; down-

loading a conﬁdential document to a notebook com-

puter could be denied if the user stays abroad. To de-

termine the location of a mobile device there are sev-

eral technologies available (e.g. GPS or CellID), see

K¨upper (2005) or Hightower & Borriello (Hightower

and Borriello, 2001) for an overview.

To implement location-aware access control a for-

malism is required to express which resources can be

accessed at which location by which users. Such a

formalism is called ”access control model” (ACM).

In our article we will introduce a location-aware ACM

that is based on the notion of role-based access con-

trol (RBAC). Location-restrictions can be assigned to

several elements in this model to provide a great de-

gree of versatility. We also introduce methods to ana-

lyze model instances based on geometric operations;

as far as we are aware this concept is novel and not

mentioned in pertinent literature yet.

The remainder of the article is structured as fol-

lows: We will ﬁrst give a short introduction to access

control models in section 2.1 before we introduce our

own model and give an example scenario in section

2.2. A formal presentation of the model will be given

in section 3; this comprehends also a simple location

model. Based on this formalization we describe some

ways to analyze model instances by geometric con-

185

Decker M. (2008).

AN ACCESS-CONTROL MODEL FOR MOBILE COMPUTING WITH SPATIAL CONSTRAINTS - Location-aware Role-based Access Control with a

Method for Consistency Checks.

In Proceedings of the International Conference on e-Business, pages 185-190

DOI: 10.5220/0001911001850190

 SciTePress

siderations in section 4. We also implemented a small

system to visualize the location constraints of model

instances and to run the analyzing algorithms; this im-

plementation will be sketched in section 5 before we

conclude in section 6.

2 ACCESS CONTROL MODELS

2.1 Basics

Access Control Models (ACM) are formal models

to describe under which conditions an information

system should grant access to resources. There are

three main groups of ACM (Samarati and di Vimer-

cati, 2001): mandatory access control (MAC), discre-

tionary access control (DAC) and role-based access

control (RBAC).

Using MAC systems subjects as well as objects

are classiﬁed according to their level of conﬁdential-

ity (e.g. ”top secret”, ”secret”, ”conﬁdential”, ”un-

classiﬁed”). Then there are rules that impose restric-

tions like ”a subject should only be allowed to read an

object if the subject’s classiﬁcation (or clearance) is at

least as high as the one of the object.” One prominent

example for such MAC is the Bell-LaPadula-model.

DAC models follow the owner principle: each object

under protection of the access control model belongs

to an owner. This owner can grant rights to perform

certain operations on that object to other subjects. Ex-

amples for DAC-models are those used by operating

systems, e.g. on Unix a user can grant the right to read

a ﬁle he just created to users of a so called group. For

the article at hand the most important group of ACM

is RBAC (Ferraiolo et al., 2003). The basic notion

is to assign permissions not to individual subjects but

rather to so called roles. Roles represent job descrip-

tions or positions within an organization. So if Alice

is hired as new ”manager” the permissions required

for this job (e.g. read payroll ﬁle, approveorder) don’t

have to be assigned individually; we just have to as-

sign the ”manager” role to Alice’s user account.

Almost all location-aware access control mod-

els that can be found in literature are extensions of

RBAC. The basic idea to obtain a location-aware

RBAC model is to switch particular elements of the

RBAC on or off depending on the user’s location,

e.g. roles (Bertino et al., 2005), the role-permission-

assignment (Hansen and Oleshchuk, 2003) or the

user-role-assignment (Chandran and Joshi, 2005).

2.2 A Location-Aware Access Control

Model based on RBAC

In this subsection we will introduce an RBAC-based

model for location-aware access control which is de-

picted in ﬁgure 1 as entity-relationship diagram. The

cardinalities in the diagram are given in the form of

(min, max)-values. For example ”(1, ∗)” as cardinal-

ity of entity ”role” in the ”role-location”-relationship

means that each role entity occurs at least once in the

relation representing that assignment. Since ”max =

∗” a role entity may occur as many times as needed in

that relation.

Each user can be assigned to several roles. Roles

again are collections of permissions. Permissions in

RBAC-models are usually considered as symbols that

have to be interpreted for the respective deployment.

In the ﬁgure we interpret a permission as a set of oper-

ations (e.g. read, write, update) that can be performed

on a given class of objects. An object class might rep-

resent a class of documents like ”customer record”.

For each object class there might be several object in-

stances, e.g. ”customer record for Mr. Meyer” and

”customer record for Ms. Miller”. The entity location

represents a location like a city, a room or a country.

We will later give a formal deﬁnition for what a loca-

tion is.

Several components of the model have a relation

to at least one location. A component is only enabled

if the respective user stays at that location, e.g. if

the role ”manager” is restricted to the locations ”lo-

cal branch Munich” and ”local branch Lisbon” this

means the role can only be used when the user is in

Munich or Lisbon. If there should be no location re-

striction we just assign the location ”universe”(which

covers the whole reference space) to the respective

component. The remaining points for the assignment

of location restrictions are:

• Restricting a user to locations means that the user

can use the system only at certain locations, e.g.

we can restrict a user to ”southern Spain” because

he has only to work in this region for the organi-

zation or he bought a software licence that covers

only this part of the country.

• Restricting a permission to locations means that

this permission should only be accessible if the

user is at the speciﬁed locations, no matter how

powerful his role is. An example is that ”access

payroll” should only be allowed while being on

the company’s premises.

• It is also possible to assign location restrictions for

individual objects, e.g. the object ”research report

no. 123” is not allowed to be accessed outside a

ICE-B 2008 - International Conference on e-Business

186

User Role

Permission

Object-Class

Object-Instance

Operation

Location

(0,*)

(1,1)

(0,*)

(1,*)(0,*)

(0,*)

(0,*) (0,*)

(1,*)(1,*)

(1,*)

(0,*)

(0,*) (0,*)(0,*) (0,*)

(0,*)

Figure 1: Access Control Model as Entity-Relationship-Diagram.

certain country because espionage is feared.

• Attaching a location restriction to the user-role-

assignment means that the given user is allowed to

play that role only at certain locations, e.g. a mo-

bile worker is only allowed to play the role ”trav-

elling salesman” in his personal sales district.

• Attaching location restrictions to the role-

permission-assignment means that the given per-

mission can be only performed using that role

when the user is at certain locations, e.g. we could

have a role ”manager” that encompasses the per-

mission ”approve order” but only within Europe.

We don’t assume that for a real-world instance of

our model all six location restrictions will be used;

but having six possible components where location-

restrictions can be assigned to gives the freedom to

choose the points that are most appropriate or natural

for the respective scenario. If location restrictions are

assigned to more than one point in the model it might

be necessary to calculate the intersection of different

location restrictions to obtain the area where the user

is indeed authorized to perform a certain permission.

To exemplify our model we give the following ex-

ample: The scenario encompasses a company with

three local branches that sends mobile employees to

facilities in a given area (e.g. to deliver goods or to

perform some kind of maintenance work). In ﬁgure 2

the location restrictions for four roles (dotted lines)

and three permissions (solid lines) are depicted as

rectangles: p

is the permission to access the payroll

ﬁle; since this is conﬁdential information this should

only be possible while staying at one of the three lo-

cal branches. p

is the permission to access customer

data; this permission is restricted to three service dis-

tricts where the facilities are that have to be served by

the company’s employees. p

is a navigation service

licensed from an external service provider; this ser-

vice is accessible only in an area that covers most of

the three services districts (licensing for a larger area

would be more expensive).

Roles r

to r

are roles for mobile workers (e.g.

Figure 2: Example for spatial constraints.

service technicians): r

is for the northern part of dis-

trict 1, r

for the southern part of that district. The

number of jobs to perform in districts 2 and 3 isn’t

big, so a single role r

is sufﬁcient for both. r

the manager’s role who has to visit facilities in all re-

stricts, e.g. to handle complaints or to acquire new

customers. Therefore this role’s location constraints

encompass all districts. Role r

has the permissions

and p

; this means that a user having r

can access

customer data (p

) in the areas where the rectangle

of r

intersects with the two rectangles for permission

; the navigation service is only accessible where the

rectangle for r

intersects with the rectangle for p

3 FORMAL DESCRIPTION OF

THE MODEL

3.1 Location Model

To give a formal description of our model and to de-

scribe spatial analyzes to be performed on instances

of the model we need a formalization of the concept

of a ”location”:

We denote the area to be covered by the ACM as

reference space or universe. Depending on the scope

AN ACCESS-CONTROL MODEL FOR MOBILE COMPUTING WITH SPATIAL CONSTRAINTS - Location-aware

Role-based Access Control with a Method for Consistency Checks

187

of the MIS universe may be the premises of a com-

pany, a country or earth’s surface. All other locations

l like cities, regions, buildings or rooms are real sub-

sets of the universe: l ⊂ universe. The set of all lo-

cations l and the universe is named locs:

locs = {l|l ⊆ universe}

With regard to the later implementation we demand

that all locations are polygons because locations will

be stored in a database system. Since we can approxi-

mate every area by a polygon with arbitrary precision

this is a weak restriction. If PT denotes the location

”Portugal” and LIS the location ”LISBON” we get:

locs = {universe, PT, LIS, .. . }.

For each location or set of locations we can calcu-

late the covered area with the function area(), which

will return a real number greater than zero:

area() : 2

locs

−→ R

If two locations of an input set overlap the intersecting

area will be counted only once.

For two locations l

, l

∈ locs we can calculate

the intersection and the union. When calculating the

intersection of two polygons we may obtain one poly-

gon, several polygons or the empty set as result, so the

intersection operator’s range is the power set of locs:

∩ l

−→ 2

locs

The union set of l

and l

can consist of one location

(if l

and l

intersect or touch each other) or two loca-

tions, but the empty set isn’t possible:

∪ l

−→ 2

locs

0, |l

∪ l

| ∈ 1, 2

There is also the set C of location classes. Location

classes are semantic categories for locations, e.g. C =

{cities, countries, buildings, . . ., unclassified}. Each

location in loc is mapped to exactly one location class

in C:

class() : locs −→ C

One class in C is ”unclassiﬁed” which is the ”dummy

class” to be used if there is no reasonable semantic

category for a location. Location classes are a mean

to support human users when browsing through the

set of pre-deﬁned locations.

3.2 Core Model

We have a set for each of the main entities of the

ACM: the set of users U = {u

, u

, . . . }, the set of

roles R = {r

, r

, . . . } and the set of permissions P =

, p

, . . . }. For the sake of brevity we don’t con-

sider the classes and objects behind a permission.

Further there are the sets UR and RP: if user u

has

role r

then (u

, r

) ∈ UR and if permission p

is as-

signed to role r

then (r

, p

) ∈ RP. Together these

sets form the set of main entities E:

E = U ∪ R ∪ P ∪ UR ∪ RP

The function loc() takes as input one of these enti-

ties and returns the subset of locations the respective

entity is restricted to:

loc() : E −→ 2

locs

The locations returned by loc() are also denoted as a

user’s, a role’s resp. a permission’s area. Example:

loc(u

) = {PT, MUN}

This means the user u

is allowed to use the system

in Portugal or Munich. If an entity isn’t restricted to

a location at all loc() just returns the universe. If we

want to express that user u

can activate role r

only

in Lisbon this would be:

loc((u

, r

)) = {LIS}

4 SPATIAL ANALYSES OF

MODEL INSTANCES

In this section we will describe some approaches to

perform spatial analyses on instances of our model

to ﬁnd inconsistent conﬁgurations. For the sake of

simplicity we don’t consider location restrictions as-

signed to user-role-assignments and role-permission-

assignments.

4.1 Coverage

Coverage is a function that takes one entity from the

set of all users, roles and permissions as ﬁrst argu-

ment (pivot entity) and one of the target categories

T = {”user”, ”role”, ”permission”} as the second ar-

gument:

cover() : (U ∪ R ∪P) × T −→ 2

locs

If the pivot entity is of the type speciﬁed by the target

category then cover() just returns the location restric-

tion of the pivot entity, e.g.

cover(u

, ”user”) = loc(u

)

If the pivot entity stands ”more left” than the target

category in ﬁgure 1 then the result is the set of loca-

tions where the pivot entity can activate at least one

entity of the target category:

• cover(u

, ”perm”) returns the area where user u

can activate at least one permission.

ICE-B 2008 - International Conference on e-Business

188

• cover(u

, ”role”) returns the area where user u

can activate at least one role.

• cover(r

, ”perm”) returns the area where with role

at least one permission can be activated.

In the opposite case (the pivot element is on the right-

hand side of the target category) the locations returned

are the area where the pivot element can be activated

by at least on entity of the target category:

• cover(p

, ”role”) returns the area where permis-

sion p

can be activated by at least one role.

• cover(p

, ”user”) returns the area where permis-

sion p

can be activated by at least one user.

• cover(r

, ”user”) returns the area where role r

can be activated by at least one user.

Due to space limitations we will only discuss

cover(p

, ”user”) in detail, which is also the most in-

teresting case: if permission p

is location-restricted

to certain locations (e.g. area where customers have

to be served, area for which a software license was

bought) we may want to check if every point of the

permission area is covered by at least one user, i.e. is

there a part of the permission area where no user ac-

cording to his roles and his own location restriction

can use that permission? If this case is given it would

mean that we had customers that cannot be served or

that we bought the software license for a too big area.

The formal deﬁnition is as follows:

cover(p

, ”user”) =

loc(p

) ∩ (

[

)∈RP

cover(r

, ”user”))

So we have to calculate the intersection of the permis-

sion area with the union of all coverages for roles that

are assigned to p

. The coverage of a role again is:

cover(r

, ”user”) =

loc(r

) ∩ (

[

)∈UR)

cover(u

, ”user”))

Here the location area of role r

has to be intersected

with the union of the area of all users that are assigned

to role r

If the permission area is smaller than the coverage,

i.e.

area(cover(p

, ”user”)) < area(loc(p

))

we have locations where the permission could be per-

formed, but no user is available who could. This is a

strong hint for an erroneous conﬁguration.

To exemplify this we give an example with two

roles and three users. For the user-role-assignment

we have:

UR = {(u

, r

), (u

, r

), (u

, r

), (u

, r

)}

Permission p

is assigned to both roles. The respec-

tive location restrictions are depicted in ﬁgure 3. The

coverage is smaller than the location restriction as-

signed to p

because there is an uncovered area (the

shaded part of the uppermost permission-area). This

part is covered by role r

. User u

and u

are assigned

to that role, but their location restrictions don’t cover

the shaded area.

4.2 Empty Assignments

We talk about an ”empty user-role assignment” when

for (u

, r

) ∈ UR the following holds:

loc(u

) ∩ loc(r

) =

The intersection between the locations assigned to the

user and the role is empty, so the respective assign-

ment is redundant, i.e. it could be removed without

changing the policy.

Further the following case shouldn’t occur:

loc(u

) ∩ cover(r

, ”perm”) =

This means that role r

was granted to user u

, but this

assignment doesn’t allow him to perform any permis-

sion. In the same way we can check for ”empty role-

permission assignment” for (r

, p

) ∈ RP:

loc(r

) ∩ loc(p

) =

Each assignment made by the administrator of a

model should be checked for these two cases; if de-

tected the administrator should be asked if he is sure

about this assignment.

5 IMPLEMENTATION

We developedan application with a Java/Swing-based

graphical user interface to have a runtime environ-

ment for instances of the proposed ACM. The appli-

cation can perform the spatial analyses covered in the

last section and is also capable of visualizing location

constraints assigned to individual entities.

The instances of the ACM are stored in a Post-

greSQL/PostGIS database management system which

provides support for working with spatial data. For

the visualization of spatial data we resorted to Open-

Jump.

OpenJump can load spatial data from a database

into different layers. We use this feature to load the lo-

cation areas for different entities of a model instance

into various layers to see how they are related. Fig-

ure 4 is a screenshot from the module of the applica-

tion that implements the coverage calculation as de-

scribed in section 4.1. On the right side we can see

the OpenJump-GUI that displays the covered and the

uncovered area of the example given in ﬁgure 3.

AN ACCESS-CONTROL MODEL FOR MOBILE COMPUTING WITH SPATIAL CONSTRAINTS - Location-aware

Role-based Access Control with a Method for Consistency Checks

189

Figure 3: Example for permission-coverage.

Figure 4: Screenshot of module for calculation of coverage along with visualization provided by OpenJump.

6 CONCLUSIONS

We started by motivating the need for location-aware

access control and proposed a RBAC-based model

where location-restrictions can be assigned at several

components to provide a great degree of ﬂexibility.

Based on a formalization of the model itself and the

underlying location model we introduced some ap-

proaches to analyze model instances based on spatial

calculations; this helps to detect erroneous location

restrictions. We also sketched the prototypical imple-

mentation of a system as runtime environment for the

model and visualization purposes.

REFERENCES

Bertino, E., Catania, B., Damiani, M. L., and Perlasca, P.

(2005). GEO-RBAC: A Spatially Aware RBAC. In

Proceedings of SACMAT ’05, pages 29–37, Stock-

holm, Sweden.

Chandran, S. M. and Joshi, J. (2005). LoT-RBAC: A Loca-

tion and Time-Based RBAC Model. In Proceedings of

the 6th International Conference on Web Information

Systems Engineering (WISE ’05), pages 361–375.

Ferraiolo, D. F., Kuhn, D. R., and Chandramouli, R. (2003).

Role-Based Access Control. Artech House, Boston

and London.

Hansen, F. and Oleshchuk, V. (2003). SRBAC: A Spatial

Role-Based Access Control Model for Mobile Sys-

tems. In Proceedings of Nordsec ’03, pages 129–141,

Gjovik, Norway.

Hightower, J. and Borriello, G. (2001). Location Sys-

tems for Ubiquitous Computing. IEEE Computer,

34(8):57–66.

K¨upper, A. (2005). Location-based Services – Fundamen-

tals and Operation. John Wiley & Sons, Chichester,

U.K.

Samarati, P. and di Vimercati, S. D. C. (2001). Access Con-

trol: Policies, Models, and Mechanisms. In FOSAD

’00: Revised Versions of Lectures Given during the

IFIP WG 1.7 International School on Foundations of

Security Analysis and Design on Foundations of Se-

curity Analysis and Design, pages 137–196, London,

UK. Springer.

ICE-B 2008 - International Conference on e-Business

190