Authorization Control

Authorization control is the process of controlling which users are allowed access to various database objects and the degree of access they can have. Typically, this is achieved by identifying all the trustees and the permissions they need when working with the data. The trustees are usually the same users, groups, and roles that are used for authentication. Common administration tasks for trustees include adding, modifying, and deleting users and groups.

Before you can set the permission properties for them, the trustees must be identifiable by the data provider. Trustees are identified by either a unique name or a security identifier. The data store should have some way to store information about each of the trustees within a collection. Normally, that information does not have any access control information stored with it but merely uniquely identifies the trustee. However, a trustee can have properties associated with it, such as a readable name and password.

Although the collection of trustees doesn't have any access control information stored with it, the database objects do. Each object has a list of access control structures. These access control structures pair a trustee identifier with a list of flags that either allow or deny access to the data. Whenever a trustee attempts to access a database object, the data provider uses the trustee's identifier to find the trustee in the list of access control structures associated with the object. If there is no list, all trustees can access the object. If there is a list and the trustee's identifier is not found in the list, access is denied to the trustee.

A trustee's identifier might exactly match an identifier in the list of trustees, or it could be found as a member of one or more trustees that represent groups. In the latter case, the provider gathers a collection of all the access control structures that apply to all the trustee identifiers. From this collection, all the flags that deny access are put into one collection and all the flags that allow access are put into another collection. Then the list of flags that deny access is examined for the particular action the trustee requested permission to perform. Any flags that deny access for the action cause the request to fail. If access is not denied by any of these flags, all the flags that allow access are examined. If no flags that allow the requested action are found, the request is denied. Otherwise, the request is allowed and the action is performed.

Note As the developer of the data provider, you might not have to implement the actual enforcement of the security as described above. This would be the case, for example, if your provider uses an external database engine library to work with the database objects in the data store and if that library enforces the security internally. However, if the database engine library does not enforce security or if the provider works directly with the database objects in the data store, you will need to programmatically implement the security control.

To create access control levels, various permission properties are available for each database object or type of database object. Each database object or type of database object is associated both with trustees and with access control structures. The access control structures are lists of permissions, sometimes called rights or access-control lists, that either allow or deny certain kinds of actions, such as reading, writing, or deleting objects.

Common access control administration tasks for objects in the data store include adding, modifying, and deleting access control structures for each database object or each kind of database object in the data store. The access control structures are used to store flags for the database object that allow or deny access to trustees.

Note All security violations are treated as normal errors within the data provider. No additional interfaces are defined in this guide to handle errors caused by security violations.

The OLE DB security interfaces described in this guide are meant to provide a standard way for consumers such as ADOX to manage the lists of trustees, trustee identifiers, and access control structures for all the database objects in any data store. You might have to translate error notifications for security violations in the data source object into the appropriate OLE DB error notification, as documented in Chapter 16, "Errors," of the OLE DB Programmer's Reference.