Access control mechanisms block diagram and their interactions. 

Context in source publication

Context 1

... CRUD expressions are rewritten before their execution and in accordance with the established access control policies. Authorization policies are encoded into functions defined for each relation, which are used to return where clause predicates to be appended to CRUD expressions, this way limiting data access at the row level. Virtual Privacy Database is an alternative to database views by avoiding some of their drawbacks such as the need for an additional view for each additional policy. With the Virtual Private Database technique, the same CRUD expression is shared by all users and automatically modified in accordance with permissions of each user. LeFevre et al. [23] propose a technique to control the disclosing data process in Hippocratic databases. The disclosing process is based on the premise that the subject has control over who is allowed to see its protected data and for what purpose. It is based on the query rewriting technique. Policies are defined using P3P [24] or EPAL [25] and comprise a set of rules that describe to whom the data may be disclosed and how the data may be used. Two disclosure models are supported for cells: at the table level each purpose-recipient pair is assigned a view over each table in the database and prohibited cells are replaced with null values; at the CRUD expressions level - protected data are removed from the returned relations of Select expressions, in accordance with the purpose-recipient constraints. Rules are stored as meta-data in the database. CRUD expressions must be associated with a purpose and a recipient, and are rewritten to reflect the ACP. SEL INKS [26] is a programming language in the type of LINQ and Ruby on Rails which extends L INKS [27] to build secure multi-tier web applications. L INKS aims to reduce the impedance mismatch between the three tiers. The programmer writes a single L INKS program and the compiler creates the byte-code for each tier and also for the security policies (coded as user- defined functions on RDBMS). Through a type system object named as Fable [28], it is assured that sensitive data is never accessed directly without first consulting the appropriate policy enforcement function. Policy functions, running in a remote server, check at runtime what type of actions users are granted to perform. Programmers define security metadata (termed labels) using algebraic and structured types and then write enforcement policy functions that applications call explicitly to mediate the access to labeled data. Rizvi et al. [29] present a query rewriting technique to determine if a CRUD expression is authorized but without changing the CRUD expression. It uses security views to filter contents of tables and simultaneously to infer and check at runtime the appropriate authorization to execute any CRUD expression issued against the unfiltered table. The user is responsible for formu- lating the CRUD expression properly. They call this approach the Non-Truman model. Non-Truman models, unlike Truman models, do not change the original CRUD expression. The process is transparent for users and CRUD expressions are rejected if they do not have the appropriate authorization. The transparency of this technique is not always desirable particularly when it is important to understand why authorization is not granted so that programmers can revise their CRUD expressions more easily. Morin et al. [30] use a security-driven model-based dynamic adaptation process to address access control and software evolu- tion simultaneously. The approach begins by composing security meta-models (to describe access control policies) and architecture meta-models (to describe the application architecture). They also show how to map (statically and dynamically) security concepts into architectural concepts. This approach is mainly focused on how to dynamically establish bindings between components from different layers to enforce security policies. They did not address the key issue of how to statically implement dynamic security mechanisms in software artifacts, in our case business tiers based on CLI. There are several other works related to access control: a distributed enforcement of the RBAC policies is proposed by Komlenovic et al. in [31]; a new technique and a tool to find errors in the RBAC policies are presented by Jayaraman et al. in [32] and, finally, Wallach et al. in [33] propose new semantics for stack inspection that addresses concerns with the traditional stack inspection, which is used to determine if a dangerous call (e.g. to the file system) is allowed. Access control is usually implemented in a three phase approach [1]: security policy definition, security model to be followed and security enforcement mechanisms. The organization of this section is also organized in three sub-sections, each one addressing one implementation phase. This paper is focused on distributed access control mechanisms. Therefore, before presenting the solution for their implementation it is advisable to clarify what are “ distributed access control mechanisms ”. Access control mechanisms are entities that act at runtime and, therefore, before advancing with deployment architectures it is important to find out if they can be represented by a general model. From the surveyed commercial and scientific literature, we can state that independently from any technique or solution, access control mechanisms can always be represented by two distinct processes: the enforcement process and the decision process. Figure 4 presents a simplified block diagram for access control mechanisms and their internal and external interactions. The basic operation is as follows: (1) client-side applications request the enforcement process to access to a protected resource; (2) enforcement process asks the decision process to evaluate if the request is authorized; (3) the decision process answers; (4) if authorization is denied, the client application is notified; (5) if authorization is granted, the request is executed by the enforcement process and, finally (6) the result is delivered to client-side applications. This block diagram and its operation is clearly the approach followed by XACML. Anyway, as we will see, it can also be used as the basic block diagram to represent other solutions. We have also intentionally used a similar XACM terminology (enforcement and decision) in order not to introduce a new complete and different one. The enforcement process is the process being used to enforce a decision about granting or denying the access to the protected resource. The decision process is the process being used to decide if the authorization to access a protected resource is granted or denied. XACML ...