The Authorization Challenge

The CycloMedia case presents a scenario in which the access to a dynamic collection of objects with spatial as well as temporal references has to be authorized to a large group of users. The authorization parameters are based on the spatial and temporal dimensions of the collection.

The traditional approach to this issue is the creation of static data sets or an authorization matrix to describe each single relation between a subject (a client or user) and each object in the collection. The construction of these data sets and matrixes is commonly based on the use of a specialized tool to evaluate the spatial relation between objects and the authorized areas.

Building and maintaining ad hoc data sets or authorization matrixes to support access control is not suitable when both the user community and the collection are large and dynamic. Furthermore, ad hoc data does not support flexible protection granularities and dynamic changes in the access control policies.

Several recently proposed solutions show various disadvantages. The main cause of those disadvantages is related to the architecture of the proposed solutions: the enforcement of the authorization is performed outside the database or after a query has been executed, thereby restricting the usage of the data. Even the GeoXACML architecture, which is currently proposed as a new standard by the Open Geospatial Consortium, is found to be problematic. It is based on standards for spatial data (GML, WMS) and authorization (XACML) and provides a solution for access control of unprotected Web Map Services without modifying the existing infrastructure. For this, it intercepts messages to a WMS, executes the retrieval task on the targeted WMS, passes the retrieved results to a policy decision point, and creates a result set based on the derived authorization decisions.

This prototype architecture, on which the concept is largely based, shows some very inefficient consequences: all data is selected from the original database, is then converted to GML, and is split and evaluated on a feature-by-feature basis against the authorization policies by an external tool. Spatial indexes in the original database thus cannot be used, and additionally the spatial comparison functions have to be implemented in a separate component. Moreover, the architecture is incapable of executing complex analysis tasks, because the data is first selected and afterward filtered against the authorization policies. Even a simple nearest-neighbor query is problematic: the nearest object selected in the first place might turn out to be inaccessible afterward. Database-Level Authorization Evaluation

Because mainstream databases have implemented spatial datatypes and spatial functions (commonly based on the SFS [spatial types and functions] standard from the Open Geospatial Consortium), it seems feasible to enforce the authorization policies on the database level. The current SQL authorization mechanism is, however, restricted to the level of tables, views, and columns. One could think of creating views for each single user, but again this approach is not scalable with a large number of users and changing policies.

Because of the above issues, current information systems typically bypass the database access control facilities and embed access control in the application program used to access the database. This can be the end-user application or a middleware application. It is problematic to embed the access control in the end-user application, if one has no control over the application source or if multiple applications are used. Changes in the authorization policies also have to be applied to multiple control mechanisms, but even then one depends on application update policies for the changes to become effective. Moreover, the risk of users or hackers submitting arbitrary queries is present. A second option is to construct the query in a middleware application. This application should then edit queries executed by the end-user applications to incorporate the authorization policies. This can, however, become tricky in the case of complex retrieval tasks and changing authorization policies. Another option is to provide several default retrieval tasks as functions to the end-user application. Although this would probably simplify the process, it directly limits the options for the users. Database-Level Authorization Enforcement

For the above reasons, fine-grained access control should ideally be both specified and enforced at the database level. Shariq Rizvi of U.C. Berkeley and others have proposed the Truman model, which is based on query modification on the database level to include authorization policies. Although others have previously discussed the concept, the Truman model generalizes the approach of query modification on the database level using a parameterized view framework. The idea behind the Truman model is to provide each user with a personal and restricted view of the complete database. To realize this, user queries are modified to make sure that the user does not get to see anything more than is allowed. The authorization policies, which are in fact logical expressions, are added to posed queries as predicates. The figure below visualizes this model.

Oracle Virtual Private Database
Oracle Virtual Private Database (VPD) has several other names within the Oracle documentation, including FGAC and RLS. Regardless of the name, VPD security provides a whole new way to control access to the data. It is based on the idea of having a defined security policy function attached to a database table or view, which is executed each time data in the table or view is queried or altered. This function returns an additional piece of SQL—called a predicate—that is attached to the original SQL's WHERE clause, before the SQL is used. It thus matches the concept of the Truman model. The query modification is done in the query optimizer and is actually performed when the SQL is parsed and executed. When the SQL is executed, it is actually the modified SQL that is executed on behalf of the user. This means that the policy function controls which rows of data are returned. The process can be thought of as a system trigger that is executed when a table is accessed that has a policy defined. An important characteristic is the dynamic nature of a VPD.

Full article...