MDAC 2.5 SDK - Technical Articles
This guide was created for developers who write OLE DB data providers. It could also be useful for developers writing OLE DB consumers and using a language, such as Microsoft® Visual C++®, that supports COM custom interfaces. It is assumed that the reader is knowledgeable in the following areas:
Implementing security in a data provider comprises two distinct processes. The first process, called security administration, defines the security policy. The second process is the enforcement of that security. This guide covers only the first process.
Security administration is the process of defining the intended security policies of the data store so that unauthorized access to the data can be prevented. This is done by creating trustee objects that represent the users that will access the data and by setting properties of existing database objects to restrict access to certain users. The security administration process also includes specifying the communication protocol between the data provider and the data store.
Security administration is usually performed by one of two common methods. The first method is to use the tools created by the vendor that created the data store. For example, Microsoft Access manages security administration for Microsoft Jet databases, and the Enterprise Manager does the same for Microsoft SQL Server® 7.0. This is often the preferred method, because these vendor-created tools provide useful interfaces specifically tailored to their products.
The second method, which is the focus of this guide, is to write programs using an application programming interface (API) for security administration. For example, the Data Access Objects (DAO) library provides automation interfaces for Microsoft Jet databases, and the SQL Distributed Management Objects (DMO) library does likewise for Microsoft SQL Server 7.0. In cases where a software component must manage security on a variety of data source objects, this second method is preferred over using product-specific tools. This guide shows how to support programmatic security administration by implementing some COM interfaces in your OLE DB data provider.
Note Another programmatic technique uses SQL Data Definition Language (DDL) security statements, such as GRANT and REVOKE, and schema rowsets to administer security settings. This technique is fundamentally the same as supporting ordinary SQL DDL statements through OLE DB command objects and therefore is not documented in this guide.
The interfaces that the data provider will implement are used by the ActiveX Data Objects Extensions for Data Definition Language and Security (ADOX) library. Client programs using ADOX will probably be the most common consumers to request these interfaces from your data provider. When you have finished implementing the interfaces described in this guide, you can use ADOX to test your data provider.
All data in the data source object, as well as the users of that data, are represented by objects in the security administration process. This guide uses the general term database objects to refer to objects such as tables, views, queries, stored procedures, schemas, or whatever encapsulated objects in the data source object are used to store data for the provider. Normally, the provider partially conceals these objects from the consumer. However, for security administration, the consumer must know exactly how they are organized and identified.
In this guide, the term trustee is used to mean the users, groups, and roles under whose security context an application or component runs. Proper security administration of a data store will describe the trustees of the data, the database objects those trustees can access, and how the data is sent to and from those trustees.
Three parts of security administration must be managed to successfully secure the data:
When all three of the preceding parts are properly implemented by the data provider, the data in the data source object can be completely secured from unauthorized access.
While briefly covering authentication and privacy, this guide primarily addresses authorization control and shows how to implement the interfaces needed to administer access control for consumers like ADOX. For complete information on making authentication and privacy properties available from your data provider, see Chapter 14, "Properties," in the OLE DB Programmer's Reference. Although the OLE DB documentation found in the MDAC SDK does not address the administration of authorization control, it does provide for authentication and privacy management using standard OLE DB interfaces and property sets.