Security Concerns in Component-Based Data Management

Don Faatz, Dr. Sushil Jajodia, Catherine D. McCollum

The MITRE Corporation


The currently defined Common Object Request Broker Architecture (CORBA) services provide capabilities similar or equivalent to the functions that make up a database management system (DBMS). Notionally, a DBMS could be considered an implementation of the Query service that encapsulates, as private methods, the capabilities of the Naming, Transaction, Concurrency, Persistence, Externalization, and Collection services. However, while a DBMS can be considered an implementation of these services, this does not guarantee that components implementing these services can be combined to form an effective DBMS. To be an effective DBMS, a collection of components must meet users expectations of functionality, performance, availability, data integrity, and access control. In fact, a close look at the list of services quickly identifies two vital but missing components, a coordinator to bind the components together into a system and a schema that describes the data being managed.

The need for a coordinator has been recognized previously. For example, Orfali [Orfali, 1997] notes the need for a "Component Coordinator" to form a working DBMS out of the collection of CORBA service implementations. The coordinator is responsible for assuring that the actions necessary to process a query against a collection of objects are performed in the proper sequence. It contributes to meeting expectations of functionality and data integrity.

The CORBA Interface Repository is a starting point for building database schema. It provides access to the interface definitions of object types or classes. However, it does not contain information on the relationships among object types or properties associated with the relationships. Using the Interface Repository and the Relationship and Property services, it might be possible to build a database schema service. However, until an interface is standardized for such a service, other services such as the Query service can't use it in an interchangeable way.

Each of the user expectations of a DBMS, functionality, performance, availability, data integrity, and access control, affect the required capabilities of the coordinator and the schema. This paper explores the security issues of data integrity and access control and their impact on the coordinator and the schema.

Data Integrity

A DBMS must guarantee "correct" results when operations are performed concurrently. In a traditional DBMS this is not a problem because the only access path to data is through the DBMS. However, in a distributed object system, any object registered with the Object Request Broker (ORB) may be accessed directly. While the Concurrency and Transaction services can provide locking and two phase commit for access to objects, these services do not guarantee two phase locking nor do they guarantee that access to a given object must use them. It is the coordinator's job to ensure that accesses use the Concurrency and Transaction services in a manner that guarantees correct concurrent execution. However, the coordinator alone cannot prevent direct access to an object through the ORB. Hence the potential exists for accesses that use the Transaction and Concurrency services to occur concurrently with other accesses that do not.

One approach to preventing direct access to objects is to use the policy domain concept introduced in the CORBA Security service (CORBASec). To determine which security policies apply to an object, CORBASec requires that objects be a member of a security policy domain. The security policies associated with a security policy domain apply to all objects that are members of the domain. The ORB is responsible for determining that a requested method invocation meets the conditions of the applicable security policies before delivering the request to the object. The security policy domain could be extended to include a data integrity policy. The data integrity policy would require appropriate use of the Concurrency and Transaction services. The ORB then becomes responsible for checking conformance to the integrity policy as well as other security policies before passing a request to an object. While this approach is a straight forward extension of an existing mechanism, it adds an additional burden to the ORB infrastructure.

A second approach to this problem builds on the concept of delegation in CORBASec. CORBASec allows traced delegation of principal credentials for access control checks. With traced delegation, the invoked object receives an ordered list of credentials, one per object on the path between the initial operation invocation and the immediate target object. This concept of traced delegation could be extended to provide not just principal credentials but the object type of and operation invoked on each object between the initial invoker and the immediate target object. Using this extension, the immediate target object could verify that the request arrived via a "valid" path that included correct use of the Transaction and Concurrency services. Each individual object would then be responsible for assuring that it only processed requests that produce correct concurrent behavior. Objects would not have to implement path checking. The coordinator could provide an interface that objects used to determine if a particular request path was valid, centralizing integrity policy decision making while distributing integrity policy enforcement. Instead of burdening the ORB, data integrity responsibility is moved back to the data management components.

Previously it was noted that the coordinator must assure that the Transaction and Concurrency services are used in a way that guarantees correct concurrent execution. This will be significantly more difficult in a distributed object system than it is in a monolithic relational DBMS. A relational DBMS that supports the Structured Query Language (SQL) performs only three operations on data, SELECT, INSERT, and UPDATE. Each of these operations has well defined semantics with respect to the type of lock needed to perform the operation. SELECT requires a read lock. INSERT, and UPDATE require write locks. An object oriented DBMS that supports the Object Data Management Group's (ODMG) Object Query Language (OQL) must handle the invocation of arbitrary object class-specific operations. To do this, the coordinator must be able to determine the semantics of the operations, read or write, to properly use the Concurrency service. The database schema is the appropriate place to store information about the semantics of object class-specific operations. Hence, the schema will be more complex and extensive than the schema of a modern relational DBMS.

Access Control

Authorization for access control in an object-oriented DBMS is very different from authorization in a relational DBMS. In a relational DBMS, users are granted access to collections of data, tables, or specific columns of tables, attributes. From an SQL query it is generally easy to determine what authorizations are necessary to perform the query. All of the tables accessed are explicitly listed in from clause of the query and all attributes accessed are explicitly listed in the select list and the where clause of the query. In an object-oriented database built from the CORBA services users are authorized to use operations on objects. To successfully authorize the use of an operation, it is necessary to authorize the use of all operations that the target operation may use to perform its function. In addition to operation semantics for locking, the database schema must contain information for each object method that identifies the other methods and object classes used by the target method during its execution. Failure to correctly authorize operation use may be more serious than failure to authorize access to the correct data. If data authorizations are incorrect, the results of queries may be incomplete, however, if operation authorizations are incorrect, the query may not be able to execute at all.

The current Domain Access Policy specified in CORBASec may not be adequate for data management. In an object oriented DBMS, it may be necessary to grant or deny access to an object method based on the path associated with the invocation. That is, it may acceptable for a user to perform operation X() on object A if operation X() is invoked by operation Y() of object B, but not acceptable if operation X() on object A was invoked in some other manner. For example, it may be acceptable for a student taking a course to access the test scores of other students in the class when using a method on a collection object that aggregates the scores and reports only the average. However, the student should not be allowed to access other students' scores directly. The current Domain Access Policy does not provide a means to specify such access control requirements. However, using the extension to traced delegation described earlier for data integrity, the Domain Access Policy could be extended to handle these authorizations.


The CORBA Services appear to be a good starting point for building component-based DBMSs. However, some additional services, such as a metadata or schema service, will be needed and some existing services will need to be enhanced. The fully encapsulated nature of CORBA distributed objects places significant requirements on the database schema that do not exist in relational databases and that may be difficult to satisfy.

Despite these difficulties, there are benefits to using components to manage data. With interchangeable components, system developers are free to choose those component implementations that best fit their needs. It is possible, for instance, that several different Transaction service implementations will be available at different costs and supporting different overall capabilities. One implementation may be fairly expensive but support an unlimited number of simultaneous transactions. Another implementation might support a limited number of simultaneous transactions but cost significantly less. Similarly, some system designers may not need the power of a full DBMS. Some systems may need to perform correct concurrent operations on non-persistent objects. Cost effective custom data management services could be developed for specialized markets by using standard services and a custom coordinator. System developers need only pay for the data management services they really need.


Cattell, R. G. G, 1991, Object Data Management: Object-Oriented and Extended Relational Database Systems, Addison-Wesley, Reading, MA.

Cattell, R. G. G. and D. K. Barry, 1997, The Object Database Standard: ODMG 2.0, Morgan Kaufman, San Francisco, CA.

Melton, J. and A. R. Simon, 1993, Understanding the New SQL: A Complete Guide, Morgan Kaufman, San Francisco, CA.

Object Management Group, July 1997, CORBAservices: Common Object Services Specification, Framingham, MA.

Orfali, R., D. Harkey, and J. Edwards, 1997, Instant CORBA, John Wiley & Sons, New York, NY.

Session, R., 1996, Object Persistence: Beyond Object-Oriented Databases, Prentice Hall, Upper Saddle River, NJ.