Submitted: 31 May 2021
Minor revision: 17 July 2021
Review 1: 0 (borderline paper)
Review 2: 2 (accept)
Review 3: 1 (weak accept)
0 (borderline paper)
This article presents a distributed authorization middleware to enforce access control. However, the motivational use case is not convincing enough, the proposed architecture is based on several strong assumptions and comparison with recent related approached should be done.
Authors should compare their approach with most recent related ones, such as for example:
2 (accept)
Summary
The paper presents an interesting approach, namely ThunQ, realizing a distributed authorization middleware for multi-tenant microservice applications to enforce access control policies on distributed application services and data. Policies can be defined both by the application provider and the tenants. The approach aims to enforce these policies early in the control-flow, such that to minimize unauthorized resource accesses or control flows, and late, deep in the data tier, such that to protect sensitive data. Realizing access-control in multi-tenant applications is challenging, since it requires flexibility, modularity, and a certain degree of adaptation to manage dynamic and distributed systems, where policies should be consistent for the entire control flow and throughout the entire application, not just at the application interface. ThunQ is realized over traditional microservice architecture, by building on top of existing approaches (e.g., partial policy evaluation, query rewriting) and technologies (e.g., Spring Cloud Gateway) and further combining and extending them, thus, to reach the overall goal of the approach. Two main components are implemented, namely (1) Gatekeeper, which extends the API gateway managing application requests and handling the early access control policies evaluation; (2) query modifier, for each microservice, which rewrites database queries such that the queries enforce access control policies on individual data records, so to handle access control policies at the level of the data tier. Evaluation results shows promising results compared to a couple of benchmarks approaches.
Comments
The paper is very well written and organized, and I enjoyed reading it. Everything is incrementally introduced, from an abstract level to the details of the approach. The paper topic is interesting and clearly relevant for the CfP, dealing with authorization enforcement in microservices applications. The open challenges the authors intend to address with their approach are clearly stated and motivated, supported by the discussed limitations of existing approaches. A use case and the background knowledge and used technologies are explained before the ThunQ middleware details are given. The security model, overall architecture and distributed policy evaluation are incrementally introduced also by means of concrete examples, supporting the understanding of the overall approach. The evaluation has been properly performed and organized and is driven by the use case scenario, through which 2 main research questions are investigated. For comparison purposes, 2 benchmark approaches for fine-grained access control in data tier are also used. Evaluation results are clearly reported and deeply discussed. The only weakness I noticed is in the literature review and, thus, the positioning of this work. I list in the following my points in support of this work as well as some concerns.
Pros
Cons
Overall, I think that this contribution is technically sound and relevant, and it contributes to the state of the art. Its positioning in the state of the art is not really satisfactory; because of this, it is not easy to have a clear idea about the novelty of the approach w.r.t. the state of the art. This is the only aspect that prevent me to give a strong accept to this work.
I strongly suggest to the authors to update the literature review by looking also for more recent approaches in the field.
Having a realistic example in which the proposal is tested gives a better understanding about how the proposal could work in real scenarios. Also, within the example, the limitations of the types of attacks are well defined.
The tool is already in Github for public use, and it can be integrated in an existing microservices architecture, as long as this includes an API Getaway.
The figures explaining how ThunQ works, where the different policies are processed, and how the residual policies are propagated towards the different microservices help quite a lot in understanding all the processes. I think it can be understood by the text alone, but having the pictures is a really good help in confirming such understanding. Besides the picture, the example with the small piece of code is also quite helpful for understanding the type of information that travels across the system.
I would remark that the type of security that ThunQ is achieving is access control based. Using the term “security” could lead into thinking that it protects against attacks, like impersonation or direct attacks against the databases, which the paper discards. The security is only related to access control, so I would change the former term towards the latter, even if it is a part of security.
It is not explained, in case of having to divide the residual policies in the query between two different microservices, whether the entire policy is sent to both, or only the attributes of the domain of the microservice get to travel with the request. In case of the former, an analysis of how this small overhead impacts the architecture could be valuable in the evaluation, since it is intended to serve a high number of users concurrently.
There is no evaluation on how the overhead of memory can affect the different microservices when adding the new functionality. An addition like this could be valuable, as many microservices are instantiated using containers that tend to have limitations in the memory available.
I think there is a problem with the terms “high selectivity in policies” and “high selective policies”. They look very similar, yet they are quite the opposite. As selectivity in policies increase, the policies are considered to be more permissive, therefore more fields are usually valid for a certain query. Higher selective policies lead to less selectivity in policies, forcing the query to check more fields, because there are less that are valid. This can lead to confusion for the reader, as the terms look quite similar.
1 (weak accept)
The paper presents ThunQ, a distributed middleware for access control in microservices applications. ThunQ provides lazy evaluation for policies in the API getaway, allowing to partially process them, if the client is allowed to perform such operation with the data available in the API getaway. The policy is partially processed, and the part that cannot be processed is then sent towards the microservices, where such data is available. The article brings evaluation on how ThunQ improves performance over postprocessing, when there are high restrictive policies.
I personally consider the idea as fitting for the conference, because of its easily integration into an existing microservices architecture. Still, I do not consider the concept as groundbreaking. It is a good work of engineering; however, it does not create any new concept. The study of the state of the art seems correct, and I have not missed any important references. I would have appreciated some experimentation on how the Thunks at the end of the request affect the system. In case this can be negligible, I would have appreciated to have such statement somewhere in the paper.
In terms of presentation, I consider the article to show a good presentation, with very useful images describing the whole process, and making it very easy to understand. The text structure is easy to read and follow. Maybe in the evaluation there is a bit of back and forth, but not too much. There is still this problem with two terms around selectivity, explained in weaknesses and corrections.
Overall, I would suggest that the paper, despite its good fitting for the conference, needs to undergo certain changes and corrections that will be explained below.
I would not mention security as a general term. The paper does already discard attacks like impersonation, or direct attacks against the databases. I would mention access control, as it is more precise with the goal of the article.
A clarification should be added for the case, where the request needs data from two domains. Is the partial evaluation passed to every microservice, or do the attributes of one domain only travel towards the microservice of such a domain? In case of the former, I would like to know, how the overhead of processing such requests affects the architecture. In case the authors consider such overhead to be insignificant, I would suggest to explain the reason behind this.
I would suggest to explain the impact of ThunQ in terms of memory in the different microservices. As it appears across the whole architecture in form of different components, an explanation of how each of them affects each instance could be valuable.
I think that the terms “high selective policies” and “high selectivity in policies” can be confusing for the reader. For that reason, I would remove high selective policies, and only use selectivity, as it already appears in the figure.