9 Access Control Systems for Geospatial Data and Applications
209
to be automatically notified about nearby traffic jams. Because in a location-aware
context the availability of the service depends on the position of the user, if the user
changes position in time, it may occur that the user is no longer in a position which
authorizes him/her to access the service. To our knowledge, this issue has not been
addressed yet.
9.5.2 The Challenge of a Distributed Architecture for Location-based
Applications
The above centralized architecture has two major drawbacks. First, the architecture is
not scalable. Suppose that an organization introduces an application in which LBSs
are provided by several applications servers. In such a case, a centralized policy enforcement creates a bottleneck since all requests for all application servers should
be first sent to the ACS and eventually dispatched to the recipients. Similarly, the
administrative operations, such as the addition or removal of a service by a service
provider, should be managed by the central security administrator. The second drawback is that it does not address the authentication issue. On the other hand, as already
remarked, relying on user login names for grant and revoke authorization is cumbersome and it is also a low level approach.
To overcome the limits of the centralized approach, we propose an access
control framework based on a decentralized architecture. Consider the following scenario: suppose that, in our campus, services are provided by various service providers
through a number of application servers AS 1 , ..., AS n . Moreover, roles are assigned
permissions to request services from different providers. Therefore, a many-to-many
relationship exists between the set of application servers and the set of roles: an individual, because of his role, can access multiple application servers, and vice versa an
application server can be accessed by individuals playing different roles. To enable
an efficient access to services and at the same time allow a simple interaction with the
application, we propose an architectural framework based on two key design choices:
(a) the access control is distributed among a set of autonomous ACS, ACS 1 , .., ACS n
where ACS j with j ∈ {1, ..., n} controls the access to application server AS j . The access to each application server is then governed by a local policy administered by a
local security administrator. Therefore, there are n local policies and n local security
administrators. (b) The enforcement of the local policy is initiated on the client side
represented by the mobile terminal and then completed on the server side.
We now describe in more detail this approach focusing in particular on the
problem of user-role authentication and policy enforcement.
User–Role Authentication
We introduce the problem of user–role authentication through an example. Suppose
that John is assigned therole student. Then when John presents such a role to the
209
to be automatically notified about nearby traffic jams. Because in a location-aware
context the availability of the service depends on the position of the user, if the user
changes position in time, it may occur that the user is no longer in a position which
authorizes him/her to access the service. To our knowledge, this issue has not been
addressed yet.
9.5.2 The Challenge of a Distributed Architecture for Location-based
Applications
The above centralized architecture has two major drawbacks. First, the architecture is
not scalable. Suppose that an organization introduces an application in which LBSs
are provided by several applications servers. In such a case, a centralized policy enforcement creates a bottleneck since all requests for all application servers should
be first sent to the ACS and eventually dispatched to the recipients. Similarly, the
administrative operations, such as the addition or removal of a service by a service
provider, should be managed by the central security administrator. The second drawback is that it does not address the authentication issue. On the other hand, as already
remarked, relying on user login names for grant and revoke authorization is cumbersome and it is also a low level approach.
To overcome the limits of the centralized approach, we propose an access
control framework based on a decentralized architecture. Consider the following scenario: suppose that, in our campus, services are provided by various service providers
through a number of application servers AS 1 , ..., AS n . Moreover, roles are assigned
permissions to request services from different providers. Therefore, a many-to-many
relationship exists between the set of application servers and the set of roles: an individual, because of his role, can access multiple application servers, and vice versa an
application server can be accessed by individuals playing different roles. To enable
an efficient access to services and at the same time allow a simple interaction with the
application, we propose an architectural framework based on two key design choices:
(a) the access control is distributed among a set of autonomous ACS, ACS 1 , .., ACS n
where ACS j with j ∈ {1, ..., n} controls the access to application server AS j . The access to each application server is then governed by a local policy administered by a
local security administrator. Therefore, there are n local policies and n local security
administrators. (b) The enforcement of the local policy is initiated on the client side
represented by the mobile terminal and then completed on the server side.
We now describe in more detail this approach focusing in particular on the
problem of user-role authentication and policy enforcement.
User–Role Authentication
We introduce the problem of user–role authentication through an example. Suppose
that John is assigned therole student. Then when John presents such a role to the