Metadata and Temporal Access Control

So far we have focused on enacting and reasoning over policies on artifacts whose contents are directly available in the underlying tables of a database. However additional metadata regarding individual objects in a database may be useful for policy making. Most database systems can store, alongside the history of an artifact, additional details such as the user name, user group, role, and purpose of the transaction that initiated the change in an artifact. The instrumentation to store this metadata alongside artifacts can easily be embedded in the underlying triggers that maintain the artifact history. The definition of the relevant view/artifact/object history in such situations can be visualized as follows: ObjectHistory = (ID, timestamp, A1, A2, . . . , AN, user, usergroup, txntype,

application, . . . , purpose)

The additional attributes user, usergroup, etc. represent metadata from the event acting on the object. Transactional metadata is often of great value to auditors, and many

business processes rely on knowledge about users, purposes, and types of transaction to move these processes forward in different directions. Consequently, many classes of business policies are specifically related to not only the contents of an artifact before and after an update, but also to the user or the application committing that change (Figure 6.2). Other examples of such policies include specifications that require “expense claims of over $50 in value must be approved by the user named Wendy” or “if an invoice is being moved from the not shipped state to the shipped state, then the change must have been initiated by a user in the logistics user group.”

Process-oriented temporal access control restrictions are generally very difficult to model in languages that are not state oriented. However, if artifacts’ histories were to encapsulate access control events as part of their definitions, then we can easily define states based on conditions associated with this additional metadata. Consequently, we could integrate process-centric, temporal access control models with business process mod- els, and they could be validated/tested within the same constraint system.

Furthermore, within the framework of policy/artifact constraint systems, we can also accommodate a mix of temporal and non-temporal access control policy models. Appli- cations of such systems include situations where different paths are taken in the lifecycle of an object based on the privileges of certain individual users. Once an object takes a particular path at such a juncture, it need no longer be restricted by the initial access control constraint. For example, this could be applied when a critical decision needs to be taken by a user who has an elevated access control privilege specific to that process (such as a supervisor), but subsequent to this decision the process need not be restricted in terms of access control. Similarly, access control event chaining can be accomplished in a manner similar to generalization of state-oriented constraints, allowing us to specify complex conditional temporal access control constraints, such as “expense claims can only be paid out by employees in the finance department, if they have previously been approved by an employee of the administration department.”

Limitations

Implementing temporal access constraints requires very little effort in addition to augment- ing definitions of artifacts to store historical metadata. Once the triggers that maintain histories of artifacts are modified, additional metadata can be treated as regular attributes to define states and enact policies. Thus, access control restrictions are rephrased as data integrity restrictions constraining how the artifact can evolve.

However, there is a major caveat for policy makers attempting to reason over such constraint systems. This business process level reasoning does not eliminate the underlying access control layers present in the database server and the operating system. That is, if an independent access control mechanism within the database engine explicitly rejects a modification, then whether a constraint system allows it or not becomes irrelevant. The temporal access control restrictions within a constraint system essentially augment the access control rules already present, and a transaction is required to pass both levels of constraints. The above fact implies that the job of the DBA is made more challenging when verifying properties about constraint systems involving access control. More specifically, the DBA must also incorporate the behaviour of the database and operating system level access control systems.

Fortunately, in most modern database systems the access control layer is relatively sim- ple to model. It primarily consists of GRANT/DENY statements for INSERT, UPDATE, and DELETE operations on tables for specific users and group. The implications of each of these conditions has to be integrated with the constraint systems. For example, if a particular user does not have permission to modify rows from a particular table, this re- striction must be appropriately transferred as a CLTL restriction on the appropriate views involving the table in question. In case of INSERT and DELETE permissions, the corre- sponding restrictions will be modelled by restricting φS(A) and/or never entering φE, if the transaction is initiated by a certain user/usergroup. In case of UPDATE, we will require a global assertion (G) mandating that a specific user is unable to modify the artifact.

Figure 6.3: An example of a workflow level constraint to enforce an enhanced exit restriction that requires that the change taking an artifact from state A to state B must take place within 7 days.

v Read access to the database

It is also important to remind the reader that our focus is restricted to maintaining integrity only; privacy restrictions are not supported. This is in contrast to general-purpose access control, which deals with restricting both the ability to modify data and the ability to read data. Since read requests generally do not impact objects/workflows and (in the classical sense) cannot violate integrity constraints, we do not address this topic.

However, we note that if a database system is “logging access requests,” i.e. a database is maintaining a history of outcomes to read/write permissions requests handled by the underlying access control engine, then implementing temporal restrictions based on a se- quence of reads/writes is plausible. A business scenario that could justify such a feature is one that requires separation of duties: “if a user has accessed certain parts of the database or made certain modifications in the past, deny the current access request.”