Encyclopedia of Database Systems

Living Edition
| Editors: Ling Liu, M. Tamer Özsu

Access Control Administration Policies

  • Elena FerrariEmail author
Living reference work entry
DOI: https://doi.org/10.1007/978-1-4899-7993-3_332-2



Administration policies regulate who can modify the authorization state, that is, who has the right to grant and revoke authorizations.

Historical Background

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 [9] 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 [8]. Later on, some extensions to the System R access control administration model, have been defined [3], 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 [2], strong and weak and positive and negative authorizations [5]. Also, administrative policies for new environments and data models such as WFMSs [1] and XML data [12] 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 [7].


Access control administration deals with granting and revoking of authorizations. This function is usually regulated by proper administration policies. Usually, if mandatory access control is enforced, the adopted administration policies are very simple, so that the Security Administrator (SA) is the only one authorized to change the classification level of subjects and objects. In contrast, discretionary and role-based access control are characterized by more articulated administration policies, which can be classified according to the following categories [3]:
  • 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 [7] 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 [9] 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.

Implementing recursive revocation requires keeping track of the grantor of each authorization, that is, the subject who specifies the authorization, since the same authorization can be granted by different subjects, as well as of its timestamp, that is, the time when it was specified. To understand why the timestamp is important in correctly implementing recursive revocation, consider the graph in Fig. 1a, which represents the authorization state for a specific privilege p on a specific object o. Nodes represent subjects, and an edge from node n 1 to node n 2 means that n 1 has granted privilege p on object o to n 2. The edge is labeled with the timestamp of the granted privilege and, optionally, with symbol “g,” if the privilege has been granted with the grant option. Suppose that Tom revokes the authorization to Alice. As a result, the authorizations also held by Matt and Ann are recursively revoked because they could not have been granted if Alice did not receive authorization from Tom at time 32. In contrast, the authorization held by Paul is not revoked since it could have been granted even without the authorization granted by Tom to Alice at time 32, because of the privilege Alice had received by Helen at time 47. The authorization state resulting from the revoke operation is illustrated in Fig. 1b. Although recursive revocation has the advantage of being the most conservative solution with regard to security, it has the drawback of in some cases the unnecessarily revoking of too many authorizations. For instance, in an organization, the authorizations a user possesses are usually related to his/her job functions within the organization, rather than to his/her identity. If a user changes his/her tasks (for instance, because of a promotion), it is desirable to remove only the authorizations of the user, without revoking all the authorizations granted by the user before changing his/her job function. For this reason, research has been carried out to devise alternative semantics for the revoke operation with regard to recursive revocation. Bertino et al. [4] have proposed an alternative type of revoke operation, called noncascading revocation. According to this, no recursive revocation is performed upon the execution of a revoke operation. Whenever a subject revokes a privilege on an object from another subject, all authorizations which the subject may have granted using the privilege received by the revoker are not removed. Instead, they are restated as if they had been granted by the revoker.
Fig. 1

Recursive revocation

SQL [7] 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).

Key Applications

Access control administration policies are fundamental in every environment where access control services are provided.


Recommended Reading

  1. 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
  2. 2.
    Bertino E, Bettini C, Ferrari E, Samarati P. Decentralized administration for a temporal access control model. Inf Syst. 1997;22(4):223–48.CrossRefGoogle Scholar
  3. 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
  4. 4.
    Bertino E, Samarati P, Jajodia S. An extended authorization model. IEEE Trans Knowl Data Eng. 1997;9(1):85–101.CrossRefGoogle Scholar
  5. 5.
    Bertino E, Jajodia S, Samarati P. A flexible authorization mechanism for relational data management systems. ACM Trans Inf Syst. 1999;17(2):101–40.CrossRefGoogle Scholar
  6. 6.
    Crampton J, Loizou G. Administrative scope: a foundation for role-based administrative models. ACM Trans Inf Syst Secur. 2003;6(2):201–31.CrossRefGoogle Scholar
  7. 7.
    Database languages – SQL,ISO/IEC 9075–*; 2003.Google Scholar
  8. 8.
    Fernandez EB, Gudes E, Song H. A model for evaluation and administration of security in object-oriented databases. IEEE Trans Knowl Data Eng. 1994;6(2):275–92.CrossRefGoogle Scholar
  9. 9.
    Griffiths PP, Wade BW. An authorization mechanism for a relational database system. ACM Trans Database Syst. 1976;1(3):242–55.CrossRefGoogle Scholar
  10. 10.
    Oh S, Sandhu RS, Zhang X. An effective role administration model using organization structure. ACM Trans Inf Syst Secur. 2006;9(2):113–37.CrossRefGoogle Scholar
  11. 11.
    Sandhu RS, Bhamidipati V, Munawer Q. The ARBAC97 model for role-based administration of roles. ACM Trans Inf Syst Secur. 1999;2(1):105–35.CrossRefGoogle Scholar
  12. 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
  13. 13.
    Zhang L, Ahn G, Chu B. A rule-based framework for role-based delegation and revocation. ACM Trans Inf Syst Secur. 2003;6(3):404–41.CrossRefGoogle Scholar

Copyright information

© Springer Science+Business Media New York 2014

Authors and Affiliations

  1. 1.DiSTAUniversity of InsubriaVareseItaly

Section editors and affiliations

  • Elena Ferrari
    • 1
  1. 1.DiSTAUniv. of InsubriaVareseItaly