Access Control Administration Policies
Administration policies regulate who can modify the authorization state, that is, who has the right to grant and revoke authorizations.
Authorization management is a an important issue when dealing with access control and, as such, research on this topic is strongly related to the developments in access control. A milestone in the field is represented by the research carried out in the 1970s at IBM in the framework of the System R project. In particular, the work by Griffiths and Wade  defines a semantics for authorization revocation, which had greatly influenced the way in which authorization revocation has been implemented in commercial Relational DBMSs. Administrative policies for Object-oriented DBMSs have been studied in . Later on, some extensions to the System R access control administration model, have been defined , with the aim of making it more flexible and adaptable to a variety of access control requirements. Additionally, as the research on extending the System R access control model with enhanced functionalities progresses, authorization administration has been studied for these extensions, such as temporal authorizations , strong and weak and positive and negative authorizations . Also, administrative policies for new environments and data models such as WFMSs  and XML data  have been investigated. Back in the 1990s, when research on role-based access control began, administration policies for RBAC were investigated [6, 10, 11, 13]. Some of the ideas developed as part of this research were adopted by the SQL standard .
SA administration. According to this policy, only the SA can grant and revoke authorizations. Although the SA administration policy has the advantage of being very simple and easily implemented, it has the disadvantage of being highly centralized (even though different SAs can manage different portions of the database) and is seldom used in current DBMSs, apart from very simple systems.
Object owner administration. This is the policy commonly adopted by DBMSs and operating systems. Under this policy, whoever creates an object become its owner and he/she is the only one authorized to grant and revoke authorizations on the object.
Joint administration. Under this policy, particularly suited for collaborative environments, several subjects are jointly responsible for administering specific authorizations. For instance, under the joint administration policy it can be a requirement that the authorization to write a certain document is given by two different users, such as two different job functions within an organization. Authorizations for a subject to access a data object requires that all the administrators of the object issue a grant request.
The object owner administration policy can be further combined with administration delegation, according to which the administrator of an object can grant other subjects the right to grant and revoke authorizations on the object. Delegation can be specified for selected privileges, for example only for read operations. Most current DBMSs support the owner administration policy with delegation. For instance, the Grant command provided by the SQL standard  supports a Grant Option optional clause. If a privilege p is granted with the grant option on an object o, the subject receiving it is not only authorized to exercise p on object o but he/she is also authorized to grant other subjects authorizations for p on object o with or without the grant option. Moreover, SQL provides an optional Admin Option clause, which has the same meaning as the Grant option clause but it applies to roles instead of to standard authorizations. If a subject is granted the authorization to play a role with the admin option he/she not only receives all the authorizations associated with the role, but he/she can also authorize other subjects to play that role.
If administration delegation is supported, different administrators can grant the same authorization to the same subject. A subject can therefore receive an authorization for the same privilege on the same object by different sources. An important issue is therefore related to the management of revoke operations, that is, what happens when a subject revokes some of the authorizations he/she previously granted. For instance, consider three users: Ann, Tom, and Alice. Suppose that Ann grants Tom the privilege to select tuples from the Employee relation with the grant option and that, by having this authorization, Tom grants Alice the same privilege on the Employee relation. What happens to the authorization of Alice when Ann revokes Tom the privilege to select tuples from the Employee relation? The System R authorization model  adopts the most conscious approach with respect to security by enforcing recursive revocation: whenever a subject revokes an authorization on a relation from another subject, all the authorizations that the revokee had granted because of the revoked authorization are recursively removed from the system. The revocation is iteratively applied to all the subjects that received an authorization from the revokee. In the example above, Alice will lose the privilege to select tuples from the Employee relation when Ann revokes this privilege to Tom.
SQL  adopts the object owner administration policy with delegation. A revoke request can either be issued to revoke an authorization from a subject for a particular privilege on a given object, or to revoke the authorization to play a given role. SQL supports two different options for the revoke operation. If the revoke operation is requested with the Restrict clause, then the revocation is not allowed if it causes the revocation of other privileges and/or the deletion of some objects from the database schema. In contrast, if the Cascade option is specified, then the system implements a revoke operation similar to the recursive revocation of the System R, but without taking into account authorization timestamps. Therefore, an authorization is recursively revoked only if the grantor no longer holds the grant/admin option for that, because of the requested revoke operation. Otherwise, the authorization is not deleted, regardless of the time the grantor had received the grant/admin option for that authorization. To illustrate the differences with regard to recursive revocation, consider once again Fig. 1a, and suppose that Tom revokes privilege p on object o to Alice with the Cascade option. With difference to the System R access control model, this revoke operation does not cause any other changes to the authorization state. The authorization granted by Alice to Matt is not deleted, because Alice still holds the grant option for that access (received by Helen).
Access control administration policies are fundamental in every environment where access control services are provided.
- 1.Atluri V, Bertino E, Ferrari E, Mazzoleni P. Supporting delegation in secure workflow management systems. In: Proceedings of 17th IFIP WG 11.3 Conference on Data and Application Security; 2003. p. 190–202.Google Scholar
- 3.Bertino E, Ferrari E. Administration policies in a multipolicy authorization system. In: Proceedings of 11th IFIP WG 11.3 Conference on Database Security; 1997. p. 341–55.Google Scholar
- 7.Database languages – SQL,ISO/IEC 9075–*; 2003.Google Scholar
- 12.Seitz L, Rissanen E, Sandholm T, Sadighi Firozabadi B, Mulmo O. Policy administration control and delegation using XACML and delegent. In: Proceedings of 6th IEEE/ACM International Workshop on Grid Computing; 2005. p. 49–54.Google Scholar