Abstract
When organizations are collaborating, their access control models need to interoperate. However, nowadays in the industry, there are too many access control models variants and, most of times; the interoperability enforcement consumes an extra effort. In this context, this paper identifies the challenges towards how to design and enforce a meta-access control model to facilitate the interoperability between the different access control mechanisms available. The problem is posed using an ontological approach. Then, the challenges are explained using a descriptive explanation of the meta access control enforcement. The core issues addressed are: access models interoperability, standardization of storage for access data and provisioning of access models.
TopIntroduction
Today, countless access control models (ACM) solutions are available in the academy and industry. Nevertheless, the recognized development of ACM, in the majority of situations, these solutions specifies and implements the structural security access concerns of a single organizational silo (Sandhu et al., 2000). Typically, ACM solutions are designed to fit and follow policies that are applied to a specific application layer of an organization. Early examples of such approach are the discretionary access control (DAC), mandatory access control (MAC), role-based access control (RBAC), time-role-based access control (TRBAC), Orcon or Chinese wall (Ferraiolo et al., 2001; 2007).
Following this problem, Ferraiolo & Alturi (2008) raise the discussion about the feasibility of designing a meta access control model (MACM) fitting any specific ACM. So far, there are no bibliographic proofs that solve this posed problem. Moreover, Baker (2009) contributes to this discussion, stating the need to define a meta-ACM rather than specifying multiple instances in order to minimize the duplication of effort. Accordingly, to this author, the first goal to achieve in this endeavor is ACM conceptualization, and exemplifies it stating that RBAC is a particular instance of a MACM.
Moreover, recent advances proposed by Korman et al. (2016) show that the myriad of ACM solutions available difficult the management of IT models. Therefore, these authors propose an ACM meta-model, designed in ArchiMate (The Open Group, 2013) to be used by the Enterprise Architects professionals. The meta-model is derived from the conceptual mapping of seventeen different ACM models. Then, ArchiMate relates the meta-model with enterprise concepts. In the end a unified meta-model for modeling authorization within enterprises is presented.
One the other hand, from a first sight, positioned in a different scientific field, interoperability is referred by Naudet et al. (2008) as “interoperability problem appears when two or more incompatible systems are put in relation”. In a broader sense, “Interoperability requirement is a statement that specifies a function, ability or characteristic, related to the capacity of a partner to ensure its partnership regarding compatibility, interoperation, autonomy, and reversibility, which it must satisfy” (Mallek et al., 2012). Therefore, interoperability is considered as a key capacity to partners’ cooperation success (Patil et al., 2007; Reul et al., 2010). However, when two or more systems are interoperating, most of times, different ACM are in place and a barrier to the interoperation appears.
Therefore, given the context of ACM and interoperability, the following research question is logically raised: How to design and enforce a meta-access control model to facilitate the interoperability between different access control mechanisms?
For short, this paper assesses the possibility of using a meta-access control model to conceptualize and instantiate many access control models. In specific, this research explores the following challenges:
- •
Access Models Interoperability: The paper uses a MACM to abstract all the concepts and relations contained in the many ACMs, and therefore creating interoperability between them.
- •
Standardization of Storage for Access Data: Standardization is realized through a single repository (and unique) for the MACM. When needed the MACM is instantiated for a specific ACM.
- •
Provisioning of Access Models: The MACM and ACM relationship enables the dynamic creation, reading, updating and deleting of access models, in order to adapt to the evolving organizational access requirements.
Key Terms in this Chapter
Session: An instance of a user’s dialog with a system is called a session.
Identity: Identity is the fundamental concept of uniquely identifying an object (person, computer, etc.) within a context. That context might be local (within a department), corporate (within an enterprise), national (within the bounds of a country), global (all such object instances on the planet), and possibly universal (extensible to environments not yet known). Many identities exist for local, corporate, and national domains. Some globally unique identifiers exist for technical environments, often computer-generated.
Object: Any resource accessible on a computer system, including files, peripherals such as printers, databases, and fine-grained entities such as individual fields in database records. Objects are traditionally viewed as passive entities that contain or receive information, although even early access control models included the possibility of treating programs, printers, or other active entities as objects.
Operation: It is an active process invoked by a subject. Early access control models that were concerned strictly with information flow (i.e., read-and-write access) applied the term subject to all active processes, but RBAC models require a distinction between subject and operation. For example, when an ATM user enters a card and correct PIN, the control program operating on the user’s behalf is a subject, but the subject can initiate more than one operation of deposit, withdrawal, balance inquiry, or others.
Permission (or Privileges): They are authorizations to perform some action on the system. In computer security literature, the term permission refers to some combination of object and operation. A particular operation used on two different objects represents two distinct permissions, and similarly, two different operations applied to a single object represent two distinct permissions. For example, a bank teller may have permissions to execute debit and credit operations on customer records, through transactions, while an accountant may execute debit and credit operations on the general ledger, which consolidates the bank’s accounting data.
Subject: A computer process acting on behalf of a user is referred to as a subject. Note that in reality, all of a user’s actions on a computer system are performed through some program running on the computer. A user may have multiple subjects in operation, even if the user has only one login and one session. For example, an e-mail system may be operating in the background, fetching e-mail from a server periodically, while the user operates a Web browser. Each of the user’s programs is a subject, and each program’s accesses will be checked to ensure that they are permitted for the user who invoked the program.
User: Refers to people who interface with a computer system. In many designs, it is possible for a single user to have multiple login IDs, and these IDs may be simultaneously active. Authentication mechanisms make it possible to match the multiple IDs to a single human user.