User Authorization in Microservice-Based Applications

Round 1

Reviewer 1 Report

The paper proposes a systematic approach for achieving fine-grained user authorization in microservice-based applications using ABAC (Attribute-Based Access Control). The authors emphasize the importance of structure preservation throughout the various phases of application development. They demonstrate the effectiveness of their approach in microservice-based applications using RESTful APIs and conclude that their approach can help developers achieve fine-grained user authorization. In general, the addressed issue is essential, and the proposed approach looks effective.

The pros of this paper include:

- The paper provides a comprehensive review of related work in the field, which can help readers understand the context and significance of the proposed approach.

- The paper fully explains the proposed approach and the tools used to implement it, which can help developers understand and apply it in their applications.

- The paper provides examples and diagrams to illustrate their approach and its effectiveness, which can help developers understand the approach more easily.

The cons or improvement opportunities include:

- The paper does not provide a detailed evaluation or comparison of the proposed approach with other existing approaches or tools. Suggest adding quantitative or qualitative comparisons to illustrate the contribution of the proposed approach.

- It would be better to explore the potential of integrating the proposed approach with other emerging technologies and standards in the field of security and access control, such as zero-trust architecture and OAuth 2.0, to illustrate the feasibility of the proposed approach.

- It would be better to address some potential challenges or limitations of implementing the proposed approach in real-world scenarios, such as scalability, performance, and maintenance.

- Please check the cross-references carefully. For example, "??1" in line 128, "?? 2" in line 244, "?? 3" in line 245, etc..

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

The references could be slightly enhanced in the Introduction section: add the references for the API paradigms REST and RPC.

To better let the readers understand the background/existing works of authorization, I suggest adding a table comparing coarse-grained and fine-grained authorization.

Please Elaborate more on the Continuous Integration and Continuous Deployment (CICD).

How much effort is needed to generate the Object Support Table?

missing all "Listing" symbols in the paper (showing ?? now)

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 3 Report

The presented work is devoted to improving the security of micro service architectures in terms of authorization processes. It should be noted that the topic of the work is certainly relevant, and the approach proposed by the authors and the results obtained have a good potential for practical application and they deserve attention. The work itself is well structured, the materials are clearly stated.

At the same time, the approach proposed by the authors, in my opinion, requires a separate discussion.

First of all, I would like to note the cumbersome method of obtaining authorization policies. The use of use case diagrams involves very painstaking and time-consuming work, both on the creation of such diagrams and their subsequent analysis. As a rule, designers tend to minimize the number of diagrams without losing the accuracy of describing the functional requirements for the system, but this approach imposes significant limitations - or rather, maximizes the number of diagrams.

Moreover, use case diagrams poorly reflect the functional and technical essence of the implementation and, often, software developers pay little attention to them.

It is also not very clear how UML diagrams are related to natural language processing. As a suggestion for the authors, it is to explore the possibilities of using tools such as PlantUML, which provide the formation of links between components initially in a text version, which could minimize and/or automate the processes of forming authorization policies.

There are also questions about the final performance of the architecture using the proposed approach. However, the authors themselves pay attention to this in section 3.4.3.

I ask the authors to pay attention that the name of the links to the listing is displayed in the form ?? throughout the text (lines 128, 244, 245, 273, etc.)

Taking into account the fact that the authors quite clearly formulated the shortcomings of the proposed approach in the discussion section, in my opinion the work can be published with minor editorial edits.

English is acceptable, the text reads well, but there are a number of document editing errors

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 4 Report

The paper “User authorization in microservice-based applications” looks like a proposal for a structure of structure and language modeling that can be used in implementing authorization for different applications.

The structure of the paper is well organized, the work is containing all the necessary chapters to demonstrate the achieving of research’s objectives, starting with Introduction, Related work, Authorization in microservice-based applications and ending with Discussions, Further work and Conclusions.

Background with related work is well referenced and all the necessary definitions for all the features are well presented.

All the languages and used libraries are presented for a better understanding of the steps and the structure of the paper. Also, it can be visualized easier, going step by step through the paper. It was a very good idea to point out two state of the art subjects which proposed, from the point of view of the authors, the best papers in the research area.

The use of examples of “listings” (12) demonstrates the research work and add value to the paper.  Furthermore, all the figures help understand the developments of authorization artifacts and the design of microservice based applications.

Threats and validity, the limitations and the future works are very well constructed and considers all the problems or difficulties that integration of microservice based applications for authorization can arise.

Some issues should be addressed to:

·         The abbreviation table from the end of the paper it's a good idea, but some abbreviations like “Q19”, “Q95” and “RPS” are missing from the table and are not defined anywhere in the paper.

·         The authors shouldn't use references in the concluded conclusions, as the conclusions should be the authors alone.

Considering the conclusions, it will be very interesting how the proposed application structure can be implemented by different users and how proposed microservice-based applications can resolve big data amount for authorization or how can the application use different features for subjects of authorization.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 5 Report

The paper presents a systematic approach to integrate authorization into microservice-based applications using Attribute Based Access Control (ABAC). The author introduces a syntax for defining authorization requirements and policies and outlines a top-down process that spans all development phases. ABAC's implementation, following a decoupled approach, enables the externalization of authorization logic from microservices, focusing them on core functions. This design allows for greater flexibility, as authorization aspects can be adjusted without altering microservice logic. The proposed process involves creating requirements, formulating policies using support tables, and implementing them with Rego. This paper is efficient; however, there are several concerns as follows:

1. The deployment and performance evaluation are well structured; however, I suggest authors make a "table of parameter settings with specifications" to improve readability for the content from line 638 to line 656.

2. The result discussion consists of only a few performance metrics; therefore, I suggest authors improve this section by adding more key indicators (e.g., Access control precision and recall, resource utilization, response time, failure rate, system throughput, etc.) With these suggested metrics included, the proposed approach can be more convincing and analyzed critically from multiple perspectives. 

3. Does "??" symbol represent "listing"? 

4. The author presented the case study well; however, listing 9 requires more explanation. Lines 8 and 10 should be addressed clearly.

5. Please express the details of the used database for baseline and proposed implementation.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 6 Report

The work is well structured and solid. There is a lot of positive work going on, especially in the technical area. I recognize that there are several points for improvement. As there are several points, I advocate major revisions, although none of them are critical.

Improvement suggestions:

1. I recommend the authors to better support this observation “The microservice architecture has become a widely popular architecture style in research and industry”. Use more than one reference. Use more up-to-date references.

2. A better aligned between the research gap and research questions is recommended. Why these RQs are more relevant than others?

3. It would be interesting in the Introduction section to clarify the difference between authentication and authorization.

4. The relevance of two running examples to demonstrate the benefits of the approach should be better addressed.

5. “?? 2” -> “Listing 2” Same applied to “??3” and others.

6. Authors note “Finally, in the phase implementation and test, the design artifacts are implemented in a programming language and tested.” It would be relevant to explain how the tests are conducted.

7. I suppose that the presentation of Figure 5 is too simplified. I realize potential and “extend> relations between the use cases.

8. Why a relational database “PostGreSQL” is used and not an object-oriented database.

9. I recognize that the discussion of the results could be improved considering the challenges of authorization highlighted in the literature. It is perhaps the weakest component of the work.

10. I consider that finish the work with this sentence is not appropriate “Integrating fine-grained authorization…”

11. I would expect to have a better analysis of future research directions.

12. Practical contributions should also be better explored.

Some formatting issues need to be checked. 

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Round 2

Reviewer 6 Report

Thanks for the great work. It is relevant and well structured. 

It is fine.