9 Access Control Systems for Geospatial Data and Applications
201
name and UniMi is the role extent, specifically the identifier of a spatial feature of
type Campus denoting, among others, a polygonal space. An individual, which is a
member of the campus, is recognized to play the role of CampusMember and thus
authorized to invoke the services associated to the role, only when located in the
polygonal extent of the campus.
Each role is assigned a set of permissions. A permission corresponds to a service.
For example, the service BookLoan of the running example is assigned to the spatial
role LibarySubscriber(MyLibrary). The terms permission and service are used in
this chapter in an interchangeable way. Like RBAC, when a user connects to the
LBS application, a new session is started. Then the user selects the roles, among
those which have been assigned to him/her that they wish to play. This set represents
the session roles and the elements of the set are said to be activated. Unlike RBAC,
however, in our model, session roles have in addition a status which is enabled or
disabled. For a session role to be enabled, the user should be logically located within
the space of the corresponding role extent. As the user moves, the status of roles
change. Therefore, depending on the position of the user, only a subset of the session
roles is enabled and permissions granted. As a result, the set of services which the
user can access at a given point in time depends on both the session roles and the
position of the user.
Role Schema and Instance
To provide a more compact representation of semantically homogeneous roles defined over different extents, we introduce the distinction between role schema and
role instance. A role instance is a role defined over a specific extent, in compliance with the role schema. Note that the terms roles instance and spatial role are
used as synonyms. A role schema defines common properties of roles with a similar meaning and thus simplifies the specification of roles and ultimately role engineering. Specifically, a role schema defines: (a) a common name for a set of
roles; (b) the type of role extent; (c) the type of logical location; (d) the mapping function relating the real position with the logical position. For example,
CampusMember(Campus, S ector, m sector ) is a schema the instances of which are
roles having the following properties: the roles have the same name
CampusMember; Campus is the type of the role extent; Sector is the type of logical
position which is computed by applying function m sector to the real position. Once a
schema is specified, the corresponding instances can be simply created by specifying the role name and its extent, for example CampusMember(UniMi). Notice that
UniMi is a feature of type Campus and defines the boundary of the spatial role.
Because roles are assigned permissions and because of the two different levels of
role representation, it seems reasonable to assign permissions to both role schemas
and role instances. The permissions which are assigned to a schema are then inherited
and shared by all the instances of the schema. For example, if we assign the service
getMap to the role schema CampusMember, it means that such a service can be
accessed by all the members of the campus. For the sake of flexibility, however,
permissions can be assigned also to single-role instances.
201
name and UniMi is the role extent, specifically the identifier of a spatial feature of
type Campus denoting, among others, a polygonal space. An individual, which is a
member of the campus, is recognized to play the role of CampusMember and thus
authorized to invoke the services associated to the role, only when located in the
polygonal extent of the campus.
Each role is assigned a set of permissions. A permission corresponds to a service.
For example, the service BookLoan of the running example is assigned to the spatial
role LibarySubscriber(MyLibrary). The terms permission and service are used in
this chapter in an interchangeable way. Like RBAC, when a user connects to the
LBS application, a new session is started. Then the user selects the roles, among
those which have been assigned to him/her that they wish to play. This set represents
the session roles and the elements of the set are said to be activated. Unlike RBAC,
however, in our model, session roles have in addition a status which is enabled or
disabled. For a session role to be enabled, the user should be logically located within
the space of the corresponding role extent. As the user moves, the status of roles
change. Therefore, depending on the position of the user, only a subset of the session
roles is enabled and permissions granted. As a result, the set of services which the
user can access at a given point in time depends on both the session roles and the
position of the user.
Role Schema and Instance
To provide a more compact representation of semantically homogeneous roles defined over different extents, we introduce the distinction between role schema and
role instance. A role instance is a role defined over a specific extent, in compliance with the role schema. Note that the terms roles instance and spatial role are
used as synonyms. A role schema defines common properties of roles with a similar meaning and thus simplifies the specification of roles and ultimately role engineering. Specifically, a role schema defines: (a) a common name for a set of
roles; (b) the type of role extent; (c) the type of logical location; (d) the mapping function relating the real position with the logical position. For example,
CampusMember(Campus, S ector, m sector ) is a schema the instances of which are
roles having the following properties: the roles have the same name
CampusMember; Campus is the type of the role extent; Sector is the type of logical
position which is computed by applying function m sector to the real position. Once a
schema is specified, the corresponding instances can be simply created by specifying the role name and its extent, for example CampusMember(UniMi). Notice that
UniMi is a feature of type Campus and defines the boundary of the spatial role.
Because roles are assigned permissions and because of the two different levels of
role representation, it seems reasonable to assign permissions to both role schemas
and role instances. The permissions which are assigned to a schema are then inherited
and shared by all the instances of the schema. For example, if we assign the service
getMap to the role schema CampusMember, it means that such a service can be
accessed by all the members of the campus. For the sake of flexibility, however,
permissions can be assigned also to single-role instances.