194
Maria Luisa Damiani and Elisa Bertino
• UA ⊆ U × R. The user assignment relation that assigns users to roles.
• AssignedU ser : R → 2
U . The mapping from a role to a set of users.
• PA ⊆ R × PRMS . The permission assignment relation that assigns permissions
to roles.
• PrmsAssignment : R → 2
PRMS . The mapping of a role into a set of
permissions.
• S essionU ser : S ES → U. The mapping from a session to a user.
• S essionRole : S ES → 2
R . The mapping from a session to a set of roles.
RBAC standard is defined at three levels, which are referred as Core, Hierarchical,
and Constrained RBAC, respectively. Core RBAC defines the minimum collection of
RBAC elements, element sets, and relations for a RBAC system to be defined. The
Hierarchical RBAC component adds relations for supporting role hierarchies. A hierarchy is a partial order defining a seniority relation between roles, whereby senior
roles acquire the permissions of their juniors. Constrained RBAC adds separation
of duty (SoD) constraints to the RBAC [13]. SoD constraints are introduced to prevent conflicts of interest arising when a single individual can simultaneously perform
sensitive tasks requiring the use of mutually exclusive duties. In the RBAC standard,
enforcement of SoD policies is realized by specifying exclusive role constraints. As
an additional level, administrative functions are defined to enable policy specification.
9.3 Motivations and State of the Art
In this section we discuss in detail relevant access control requirements arising in the
context of geospatial applications and contexts, and then we survey related research
proposals and approaches.
9.3.1 Requirements for Spatially Aware Access Control
Geospatial data have a strategic relevance in various contexts, such as emergency
response, homeland security, marketing analysis tools, and environmental risks
control procedures. Most applications in these areas require a fine-granularity flexible access control to geospatial data. A possible naive approach to support access
control is to build ad hoc data sets (maps) for each type of access the administrator wants to grant: this has been the cartographic approach applied for many years
in the past. Such an approach is not suitable when the user community is large and
dynamic—which is today often the case in Web-based systems—and when the data
and the access control policies dynamically change—which is the case in applications such as emergency response. Another major drawback of the conventional
approach is that it does not support flexible protection granularities in the access
control policies, and it does not account for various levels of representation that data
may have in a geospatial database. The introduction of integrated data management
systems for geospatial data, such as current integrated GIS systems, characterized
Maria Luisa Damiani and Elisa Bertino
• UA ⊆ U × R. The user assignment relation that assigns users to roles.
• AssignedU ser : R → 2
U . The mapping from a role to a set of users.
• PA ⊆ R × PRMS . The permission assignment relation that assigns permissions
to roles.
• PrmsAssignment : R → 2
PRMS . The mapping of a role into a set of
permissions.
• S essionU ser : S ES → U. The mapping from a session to a user.
• S essionRole : S ES → 2
R . The mapping from a session to a set of roles.
RBAC standard is defined at three levels, which are referred as Core, Hierarchical,
and Constrained RBAC, respectively. Core RBAC defines the minimum collection of
RBAC elements, element sets, and relations for a RBAC system to be defined. The
Hierarchical RBAC component adds relations for supporting role hierarchies. A hierarchy is a partial order defining a seniority relation between roles, whereby senior
roles acquire the permissions of their juniors. Constrained RBAC adds separation
of duty (SoD) constraints to the RBAC [13]. SoD constraints are introduced to prevent conflicts of interest arising when a single individual can simultaneously perform
sensitive tasks requiring the use of mutually exclusive duties. In the RBAC standard,
enforcement of SoD policies is realized by specifying exclusive role constraints. As
an additional level, administrative functions are defined to enable policy specification.
9.3 Motivations and State of the Art
In this section we discuss in detail relevant access control requirements arising in the
context of geospatial applications and contexts, and then we survey related research
proposals and approaches.
9.3.1 Requirements for Spatially Aware Access Control
Geospatial data have a strategic relevance in various contexts, such as emergency
response, homeland security, marketing analysis tools, and environmental risks
control procedures. Most applications in these areas require a fine-granularity flexible access control to geospatial data. A possible naive approach to support access
control is to build ad hoc data sets (maps) for each type of access the administrator wants to grant: this has been the cartographic approach applied for many years
in the past. Such an approach is not suitable when the user community is large and
dynamic—which is today often the case in Web-based systems—and when the data
and the access control policies dynamically change—which is the case in applications such as emergency response. Another major drawback of the conventional
approach is that it does not support flexible protection granularities in the access
control policies, and it does not account for various levels of representation that data
may have in a geospatial database. The introduction of integrated data management
systems for geospatial data, such as current integrated GIS systems, characterized