An access control system for a web map management service ...

An Access Control System for a Web Map Management Service Elisa Bertino DICO University of Milan - Italy [email protected]

Maria Luisa Damiani DICO University of Milan - Italy [email protected]

Abstract In this paper, we present an access control model for spatial data on Web. Such a model is based on the following assumptions: first, spatial data consist of objects with sharp boundaries located in a geographical space; second, data are manipulated through the operations provided by a Web Map Management Service. The goal of the system is to control the way data are accessed by users having different profiles. We propose an extension of classical models based on authorization rules by assigning authorizations a geographical scope. In such a way, the operations users may execute on spatial data may vary, depending on user identity and object position.

1.

Introduction

Current applications increasingly require that spatial data be managed through the Web. Map delivery, traffic information systems and location based services are only few of the many challenging applications involving the dissemination of spatial data through the Web. However, it is very often the case that users need not only to display data but also to interactively modify them. It is also important to notice that in many cases updates are performed by remotely connected users and that, moreover, the way spatial data are usually presented to users is through maps. The use of maps is crucial for correctly geo-referencing data. Think for example of surveyors equipped with mobile devices that collect data on the field and feed a remote database; this operation requires first a download of the map with the layers of interest, next the editing of spatial data and finally the upload of the new spatial objects in the remote database through the Web. Currently, visualization and editing of spatial objects on Web is supported by several commercial map management systems [8, 9]. However, an issue that has not been much investigated is that of enforcing controlled access to spatial data, in order to ensure

Davide Momini DICO University of Milan - Italy

confidentiality and integrity of information. Ensuring confidentiality means preventing improper disclosure of information to users non authorized to see it. Ensuring integrity means protecting data from unauthorized modifications and thus preventing non-authorized users from inserting or modifying data in the database [4]. In this paper we address the above issue by proposing an access control model for spatial data on Web. The model is based on the following assumptions: first, spatial data consist of objects with sharp boundaries located in a geographical space; second, data are manipulated by remote users through the operations provided by a Web Map Management Service that mediates between users and data. The goal of the system is to control the way data are accessed by users having different profiles. The approach proposes an extension of the classical access control model based on the notion of authorization rule [4]. The central idea is to assign an authorization a geographical scope, namely a bounded region in which the authorization is valid. Therefore, operations that users may execute on spatial data may vary, depending on user identity and object position. Issues concerning data protection have been widely investigated for conventional database management systems [3]. Moreover, there have been several efforts extending conventional access control models to deal with new data types and models. Such efforts include access control models for Web pages and XML data, temporal access control models [5], extended access control models for relational databases [6], and access control models for Digital Libraries [2]. As far as we know, our approach is the first one to propose a comprehensive access control model for spatial data. The only other approach which is somehow related to our work is a proposal for an access control system for a database of geo-referenced Earth images [1]. The goal of such system is to support a controlled dissemination of satellite images at different levels of resolution. However, such system has limited applicability, since it deals with a very specialized type of data, that is, satellite image data, and therefore it does not take into account existing standards for spatial data. Moreover,

Proceedings of the 14th International Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE’04) 0-7695-2095-2/04 $20.00 © 2004 IEEE

the system has not been implemented and therefore its actual applicability has not been assessed. Finally, issues related to the access of image data through Web are not addressed. By contrast, our model is based on existing standards; it has been implemented and its architecture is based on the modern Web service paradigm. The work reported in this paper has been carried out in the framework of a project investigating a collaborative approach to environmental monitoring. Such application, presented in the following as case study, consists of a Web Map Management Service supporting the update and sharing of environmental data concerning major river basins in Italy. Environmental data can be acquired by different organizational units and even by groups of volunteers spread on the territory. The spatial database can thus be modified by different kinds of user, having different access rights. The paper is organized as follows: next section introduces the overall context and the basic assumptions; Section 3 presents the access control system whereas Section 4 presents all relevant concepts concerning authorization administration. Some final remarks conclude the paper.

2.

2.1

Preliminary assumptions

notions

and

basic

Spatial data model

We start describing the spatial data model we use. A spatial data model defines the way spatial information is structured in a database in terms of logical, that is, user visible, data structures. Spatial data models can be roughly classified in vector models and raster models. Vector models are best suited to describe objects with sharp boundaries located in a geographical space, like roads, buildings and so on; raster data models are instead more appropriate to describe spatial distributions, like temperature, altitude and georeferenced images. In our work, we have adopted the vector model defined by the OpenGIS Consortium (OGC) based on the notion of simple spatial feature [11]. Such a model is actually only a subset of the most recent abstract feature model adopted by OGC[14]; nevertheless it has the advantage of being supported by most commercial platforms for spatial data management. In such a model, a spatial feature (feature for short) describes a real entity through a set of attributes defined on simple types (thematic attributes ) and one or more attributes defined on geometric types (geometric attributes). The geometric types are the so called Well-Known-Types of the OpenGIS Geometry: point, line, polygon, collection of geometries, like multi-point, multi-line, multi-

polygon. Homogeneous features are collected in feature classes each denoted by a unique name. A spatial reference system is specified for each feature class, so that the values of geometric attributes can be properly interpreted as locations on the Earth surface. Moreover a set of operations is defined for features. In general, feature classes are implemented in terms of relational or object-relational tables, whereas feature attributes are mapped onto table fields. Depending on the data management architecture, geometric data, that is, a list of coordinates, are mapped onto a field of either BLOB type (Binary Large Object) or of an abstractdata-type. Note that the notion of feature class is close to that of relational table. However the level of abstraction is different; a table should be more properly seen as a data structure implementing a spatial feature class. Typical queries on features select objects using some spatial criteria, such as metric and topological criteria, whereas the creation of a feature entails the definition of its geometry and the specification of its attributes.

2.2

Spatial data on Web

Because several applications require spatial features to be interactively accessed through the Web, the architecture of Web map management applications is usually organized according to the well-known threetier architecture consisting of Presentation, Application and Data Storage layers. The Data Storage layer consists of file and database servers; the Application layer implements the operations requested by the application. In general, the core of the Application layer is the Web Map Server consisting of a geo-processing engine running of top of a Web Server handling the communication over the network. Last, the Presentation layer on the client side consists of either html pages or specialized programs, such as Java code, and plugs in (Fig.1). Geo engine Html/Java … Presentation Web Server

Data storage

Web Map Server

Figure 1. General architecture An important remark to be made is that the spatial features can be transferred from the server to the client in the form of either image maps or vector maps, depending on the Web Map Server capabilities. In the first case, the resulting map may be presented to the

Proceedings of the 14th International Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE’04) 0-7695-2095-2/04 $20.00 © 2004 IEEE

user through a simple Web browser. Conversely when the features are transferred in vector format, a thick client, such as a Web browser extended with a plug in or a Java program, is used for data display. In such a case, however, the client is not only in charge of the graphical visualization but also of some simple operations on maps such as zoom and local editing. Because this architecture ensures better performance when maps are used interactively, we assume that features are transferred in a vector format and that geo-processing is thus distributed on both client and server.

2.3

outcome consists of the points highlighted in the magnifier window.

The case study

The work presented in this paper originated from a Web map management application, developed for the regional offices of a widely known environmental organization (WWF)[10]. The purpose of the application is the acquisition and sharing of environmental data on some major river basins in Italy. The core component of the architecture is a spatial database storing entities in form of spatial features. Spatial data regard essentially: soil use, critical elements in proximity of a river such as illegal waste deposits/buildings and administrative entities. Features can be queried and interactively modified by invoking a set of operations provided by the Web Map Server. Features are transferred in a proprietary vector format and presented to the user through a plug-in. The main operations of the Web Map Server are briefly described in Table I. Table I. The Web service operations Get Features Returns the geometries of the input class instances GetFeatureInfo Returns the thematic attribute values for an input feature MetricQuery Selects features using distance-based criteria TopologicalQuery Selects features using topological criteria CreateThematism Classifies features assigning a different symbology to each class InsertFeature Inserts a new feature DeleteFeature Deletes the input feature An example of user interaction is shown in Figure 2. Through a Web browser, the user issues a request for a topological query by entering the expression (in Italian in the picture): “Select damaged embankments within poplar woods”. The request is interpreted first by the client that forwards a query to the Web Map Server; hence the resulting features are properly encoded for transfer and sent back to the client which finally displays them through a map. In the picture the query

Figure 2. User interaction The goal of the work reported in this paper is to enhance this application by differentiating the way data are accessed and modified by users having different profiles. For example, the operations that modify the status of the database, should be strictly controlled. Only users in charge of data survey should be authorized to enter or remove features. Another important requirement is that users should be allowed to view and modify data only in some given regions. In order to account for these requirements, we propose the usage of an access control mechanism for filtering user requests.

3.

The access control system

The access control system is a component in charge of ensuring data protection within a data management system. Basically, data access is controlled through a set of authorization rules stating who can access which resource for doing what. Each authorization rule, in its basic form, consists of a triple: . The subject indicates who can access the data resources, the object is a resource identifier, the privilege is the kind of action that can be performed by the subject on the given object [4]. When a user tries to access a resource, the request is checked against the set of authorization rules. If the match is successful the user can access the resource; otherwise the request is discarded. Authorization rules are granted in accordance to an administration policy. We adopt a discretionary access control policy; it means that subjects with proper administration authorizations can grant and revoke authorizations to other users at their discretion. In general, the definition of an access control mechanism entails the specification of - the authorization data model - the administration model and operations.

Proceedings of the 14th International Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE’04) 0-7695-2095-2/04 $20.00 © 2004 IEEE

In the remainder of this section we step-wise introduce the authorization model by starting from a basic model and then extending it. The administrative operations will be discussed in the subsequent section.

3.1

Subjects, objects and privileges

In order to define our model, we need to define the subjects, the objects and the privileges. For what concerns the subjects, we assume that the users of the Web service are registered users that are classified on the basis of the role they play in the organization. An example of role is that of “regional officer”. A user is assigned one or more roles and moreover each role is assigned a set of privileges. Each role is identified by a name. The role Administrator is a system-defined role and represents the top-level role. In our model, the various roles represent authorization subjects. The object of an authorization is a spatial feature class. A feature class denotes a set of instances or features. An authorization on a given feature class states which instances can be accessed, in which way and by which roles. For example, an authorization can state that data on illegal waste deposits can only be inserted by “surveyors”. Note that in our model it is not possible to define authorization rules for objects at a finer level of granularity, on single features for example, or on feature class attributes. This limitation, however, does not seem restrictive for the purpose of the application. The operations that can be performed on a given feature class by a role depend on the privileges assigned to that role. An interesting issue concerns the criteria used for specifying the set of privileges. The question makes sense because the operations that can be invoked are only those implemented by the Web Map Server and exposed through a Web service interface. In principle, one could think of defining a privilege for controlling the accessibility of each single operation. This approach however lacks flexibility; if a new operation is added to the Web service, a new privilege needs then to be introduced in the access control system. A more flexible approach is based on using privileges at a coarser granularity. Privileges are defined by partitioning the operations and associating a privilege with each class of operations. The effect is that a user with a given privilege, say P, has the right to invoke all the operations belonging to the class associated with P. The general criteria suggested for partitioning the set of available operations is to include in the same class the operations that are homogeneous with respect to the application security requirements. To exemplify such concept, we report few privileges specified for our application: the Notify privilege controls the execution of the operations for feature insertion and deletion; the Analysis privilege controls the execution of the different querying operation; the

ViewGeometry privilege controls the single operation of GetFeatures, finally the ViewAttribute privilege controls the operation of GetFeatureInfo. At this point we can define more precisely our notion of authorization rule. Definition 1 (Basic authorization) Let R be a set of roles, FC the set of feature classes, O the set of Web service operations, P the set of privileges defined as a partition over the set O. A basic authorization rule is defined as a triple where rR, f FC, p  P. Example 1: The rule authorizing a surveyor to notify illegal waste deposits can be expressed as follows: .

3.2

Privilege dependencies

In general, dependencies may exist between authorizations; this means that a privilege cannot be granted independently from some other privileges. As an example, consider again our running application; we assume that the Notify privilege cannot be given unless the viewing privileges (ViewGeometry and ViewAttributes) are also granted. Such a requirement is reasonable because it would make little sense to modify a spatial object that cannot be viewed. In such a case we say that the Notify privileges depends on both ViewGeometry and ViewAttributes privilege. A definition of privilege dependency is given next. Constraint 1 (Constraint on privilege dependency) Let r be a role, fc a feature class, p1, p2…, pn privileges. We say that p1 depends on p2…pn (written as p1Æp2..špn) iff the existence of the rule: a1= implies the existence of the rules: a2=,...,an=. The rule a1 is said to be dependent on a2...an (written a1Æa2š…an). Example 2. The dependency discussed above can be expressed in a simple way as follows: Notify Æ ViewGeometryšViewAttributes As a consequence, given a1= (r, fc, Notify), a2=(r,fc,ViewGeometry) and a3=(r,fc,ViewAttributes) it follows that a1Æ a2š a3 .

3.3

The authorization window

The basic authorization model introduced so far centred on subjects, objects and privileges is not sufficient to model the fact that the authorizations may be spatially constrained, that is, depending on the user profile, the scope of the authorization may be limited to a region. For example a “regional officer” might be authorized to view only the illegal waste deposits in the region where he is located. In order to support such requirement, we extend the basic model by introducing the notion of authorization window. An authorization

Proceedings of the 14th International Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE’04) 0-7695-2095-2/04 $20.00 © 2004 IEEE

window indicates the geographical scope of the authorization, that is, the portion of the territory to which the authorization applies. In this way, we can state that a given role has some privilege on some feature class exclusively for the features located in the window area; the privilege would not apply to features located outside that area. As an example consider the following authorizations: a= b= . The first rule states that role r1 can notify illegal waste deposits located in Zone1; the second rule states that role r2 can notify features of the same class located in Zone2 (to improve readability windows are denoted simply by a name). Those authorizations would then be checked against every insertion/deletion operation. If subjects r1 and r2 try to edit an element outside their respective authorization windows, an error occurs. The window of an authorization has thus a geometric shape. For sake of simplicity, we consider the geometry of the window be exclusively of (OGC compliant) polygonal type. For what concerns the semantics of the spatial relationship between features and window (within an authorization rule), it can be defined as follows: a privilege p applies to a feature f on the authorization window w iff the f overlaps w, that is, the feature shares at least one point, either internal to the object or on the boundary, with the window. A concise definition of an authorization rule extended with the concept of window is given next. Definition 2 (Authorization with window) Let Polygon denote the set of polygonal geometries. An authorization rule with window is a tuple where r R, fcFC, p P, w Polygon.

3.4

Constraint on authorization windows

The introduction of windows in authorization rules, however, requires revisiting the notion of dependencies between privileges in that a dependency between the privileges p1 and p2 induces a spatial constraint between the windows w1 and w2 in the corresponding authorizations. An example can clarify the concept: Example 3. Consider the following authorizations: a= b= . The authorizations state that role r can view the waste_deposits overlapping region wb and notify waste_deposits in region wa. However the Notify privilege has been defined as dependent on ViewGeometry (NotifyÆViewGeometry) and that is like saying that an object cannot be created/deleted unless it can be viewed. As a consequence, the window in which new features can be inserted, that is, wa, must

necessarily be contained in or be coincident with the window in which features are displayed, that is, wb, A formal definition of the above constraint is given in what follows: Constraint 2 (Constraint on authorization window) Let a1= and a2= be two authorizations rules defined for the same role r and feature class fc but on two different privileges p1 and p2. If p1Æp2 then w1Ž w2.

4.

The authorization administration policy

After having introduced the authorization model, we can now discuss the administration policy for the authorization rules, that is, how authorizations are granted and revoked. The administrative operations are by default performed by the system-defined role “administrator”. The administrator is given the whole set of privileges for the whole set of feature classes. The administrator can create/delete users, create/delete roles and grant/revoke authorizations. Moreover, the administrator can delegate someone else to perform these administrative functions. For this reason, the administration policy is decentralized. The mechanism used for delegating administrative functions is the classical mechanism of the grant option [4]. Any role which has given a privilege on a feature class with the grant option can administer the privilege on that feature class. Accordingly, the previous definition of authorization rule is extended as follows: Definition 3 (Authorization rule with grant option) Let R be a set of roles, FC the set of feature classes, P the set of privileges, W the set of Polygons. An authorization is defined as a tuple: , where rR, f FC, p  P, wW, grR, gr_op {true, false}. The boolean variable gr_op indicates whether the role has the grant option and thus can administer the privilege on the feature class; gr indicates the role granting the authorization. However, a role having a privilege on a feature class in a given window cannot use, by definition, the privilege outside that window, neither indirectly by delegating the administrative functions. As such if an authorization has the grant option, it can be granted to other roles, but necessarily on the same window or a portion of it. Such a constraint can be expressed as follows: Constraint 3 (Constraint on authorization rule grant) Let a= be an authorization granted to role r1. The privilege p on feature class fc can be granted by r1 to r2 through the authorization b= iff the window of b is contained in the window of a, that is, wbŽ wa.

Proceedings of the 14th International Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE’04) 0-7695-2095-2/04 $20.00 © 2004 IEEE

4.1

Grant and revoke operations

Finally, we illustrate the operations for creating and revoking an authorization. We consider first the operation of rule creation. Consider a rule a= where the role r is different from administrator. The rule a can be added to the rule set iff it is consistent. Intuitively a rule is consistent if no constraint is violated. A more formal definition is given in the next: Definition 4 (Authorization rule consistency) The authorization rule a= is consistent iff the following constraints are satisfied: a) Constraint 1 and constraint 2 must hold, that is, for each privilege pi such that pÆ pi, the authorization ai= must belong to the rule set and w Ž wi b) Constraint 3 must hold, that is, let b = be the corresponding authorization given to the grantor of a; then the relationship wŽ wb must hold. The operation of creation simply checks the constraints and, if they are satisfied, inserts the new rule. For what concerns the revoke operation, an authorization rule can be revoked only by the grantor. However, in order to preserve the consistency of the set of rules, an authorization rule cannot be revoked unless the depending rules are revoked as well. Furthermore, in case the authorization rule has the grant-option, the revoke affects as well the rules that have been directly or indirectly granted to other roles. The general techniques that can be applied in this case are called respectively recursive revoking and non-recursive revoking [6]. Because in this case we do not see any reason for preferring one technique instead of the other, the decision is left to the grantor and thus the revoking method is one of the parameters of the operation. When a rule has no grant option and no dependent rules it can be simply deleted from the rule set.

5.

Final remarks

A prototype of the access control model has been developed using a commercial Web GIS platform, Intergraph Geomedia Webmap¥ 5.1. For what concerns the architecture of the application, the connection to the Web Map Server is supported through an authentication service based on username/password. When the user logs in, he is assigned a role and thus a set of privileges on features. When a role issues a request for a given Web Service operation, the program implementing the operation checks first whether and where the privilege applies. Next the operation is eventually performed within the window of the rule. Otherwise should the rule

not exist the operation is not authorized. For the storage of the authorizations a spatial database compliant with OGC simple feature model is used. Summarizing, we have presented a first contribution to the problem of providing a controlled access to spatial features on Web. Open issues include: how to make the approach scalable in order to ensure an efficient access control; how to define a flexible architecture for the secure Web Map Management application. Another research issue is the extension of authorization model to account for the current standardization efforts on Role Based Access Control systems.

6.

References

[1] V. Atluri., P. Mazzoleni , “A Uniform Indexing Scheme for Geo-spatial Data and Authorizations”, 16th IFIP WG11.3 Working Conference on Database Security, July 2002. [2] N.Adam, V.Alturi, E.Bertino,E.Ferrari, “A Content-based Authorization Model for Digital Libraries”, IEEE Trans. on Knowledge and Data Engineering, Vol. 14, N.2, March/April 2002. [3] E.Bertino, S.Jajodia, P.Samarati, “A Flexible Authorization Mechanism for Data Management Systems”, ACM Trans. on Information Systems,Vol.17, No.2, pp.101140, April 1999. [4] E. Bertino, E. Ferrari., “Data Security”, in Proc. of COMPSAC 1998. [5] E.Bertino, C. Bettini, E. Ferrari, P. Samarati, “An Access Control Model Supporting Periodicity Constraints and Temporal Reasoning”, ACM Trans. On Database Systems, Vol.23, N.3, pp.231-285, September 1998. [6] E. Bertino, P. Samarati, S. Jajodia , “An Extended Authorization Model for Relational Databases”, in IEEE Trans. on Knowledge and Data Engineering, Vol.9, N.1, January/February 1997. [7] S. Castano, M.G. Fugini, G. Martella, P. Samarati, Database Security, Addison-Wesley, 1995. [8] ESRI, ArcIMS 4 Architecture and functionalities”, ESRI White Paper, http://www.esri.com. [9] INTERGRAPH, Geomedia http://www.intergraph.com/gis/gmwm./

Web

Map,

[10] D. Momini., Sistemi Informativi Geografici via Web: studio di un caso, Tesi di Laurea, Universita’ degli Studi di Milano, 2003. [11] OpenGIS Consortium, OpenGIS Specification for SQL, OGC 99-049, 1999

simple

Features

Proceedings of the 14th International Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE’04) 0-7695-2095-2/04 $20.00 © 2004 IEEE

[12] OpenGIS Consortium, Web Feature Implementation Specification, OGC 0-058, 2002

Server

[13] Open GIS Consortium, Web Map Service Implementation Specification, OGC 01-068r3, 2001 [14] Open GIS Consortium, Feature Geometry (ISO 19107) Spatial Schema, OGC 01-101, 2001

Proceedings of the 14th International Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE’04) 0-7695-2095-2/04 $20.00 © 2004 IEEE