A method for implementing distributed initialization of permission metadata

Abstract

The present invention provides a method for implementing distributed initialization of permission metadata, which includes a distributed storage process of permission metadata, in which an iam folder is created under the root path of each application to store the permission metadata change file of the application; an agent process for collecting and reporting permission metadata, in which the agent is a relatively single and independent program code running in an application, and is mainly used to collect the content of the permission metadata change file under the iam folder under the root path of the application, and report it to a liquibase server; a change execution service liquibase server process, in which after receiving the change file, the liquibase server executes the change file into the permission database of the iam through liquibase; and a permission database process, in which all permission metadata managed by IAM are centrally and uniformly stored in the permission database.

Description

Technical Field

[0001] The present invention relates to the technical field of database initialization, and in particular to a method for implementing distributed initialization of permission metadata. Background Art

[0002] With the rise of microservice architecture, large monolithic applications are split into many microservice applications with relatively independent functions. Each microservice application generally has its own independent database and data that needs to be initialized. Some of the data that needs to be initialized needs to be initialized to the database of other applications, such as permission metadata needs to be initialized to IAM (access control). This brings up a question: how to initialize the initialization data of a microservice application into different databases?

[0003] A common practice in the industry is to split the initial session data into different applications. For example, permission metadata is uniformly stored in the IAM application and initialized through the IAM application. However, this method has a big disadvantage, that is, business applications are heavily dependent on IAM applications. For example, if a business application adds a new interface, it is necessary to register a permission metadata in IAM at the same time. If the business application needs to release a new version, then IAM needs to release the version synchronously. This model is unsustainable in a cloud environment with many microservice applications and frequent iterations. Summary of the invention

[0004] The embodiment of the present invention provides a method for implementing distributed initialization of permission metadata, which can improve the security of accessing a server.

[0005] The implementation methods of distributed initialization of permission metadata include:

[0006] The distributed storage process of permission metadata creates an iam folder under the root path of each application to store the permission metadata change file of the application;

[0007] The agent process of collecting and reporting permission metadata. The agent is a relatively simple and independent program code running in the application. It is mainly used to collect the content of the permission metadata change file in the iam folder under the root path of the application and report it to the liquibase-server;

[0008] During the change execution service liquibase-server process, after receiving the change file, Liquibase-server executes the change file into the iam permission database through liquibase.

[0009] Optionally,

[0010] During the distributed storage process of permission metadata, the carrier of the permission metadata is an xml file that conforms to the liquibase specification;

[0011] Its file format is as follows:

[0012] <?xml version="1.0" encoding="UTF-8"?>

[0013] <databaseChangeLog

[0014] <changeSet author="xxx" id="xxx">

[0015] <insert tableName="Permission metadata data table name">

[0016] <column name="Column name" value="Value" / >

[0017] ……

[0018]

[0019]

[0020] 。

[0021] Optionally,

[0022] During the agent process of collecting and reporting permission metadata, the manifestation of the agent is a jar package in the Java platform. The application only needs to add the jar package to the application, and the agent will start with the startup of the application. Moreover, the agent reports and notifies the liquibase-server to execute the changes of the permission metadata, and the liquibase-server will return an indication of success or failure.

[0023] Optionally,

[0024] During the agent process of collecting and reporting permission metadata, the Agent supports automatic retry. If the liquibase-server execution fails, the agent will retry after a period of time (such as 60 seconds) until it succeeds or times out (for example, if the application has been starting for 24 hours and still fails to retry successfully, it will no longer retry).

[0025] Optionally,

[0026] During the change execution service liquibase-server process, the Liquibase-server is mainly responsible for receiving the permission metadata change file reported by the agent and further executing it into the IAM database through the open-source tool liquibase toolkit.

[0027] Optionally,

[0028] When changing the execution service liquibase-server, the main logic is as follows:

[0029] Receive the liquibase change files uploaded by the service application, and store the change files of each service application in a separate path. For example, the change file storage path of the cloud server is db / changelog / iam / master / ecs, and the change file storage path of the relational database is db / changelog / iam / master / rds.

[0030] Get a link to the IAM permissions database.

[0031] Execute the liquibase change file in the specified path to the IAM permission database through the liquibase tool interface.

[0032] Feedback the execution result to the caller.

[0033] Optionally,

[0034] Liquibase is an open source database refactoring tool for tracking, managing, and applying database changes. It saves all database changes (including structure and data) in XML files for easy version control.

[0035] Optionally,

[0036] In the permission database process, each application resource, such as interface, URL, menu, etc., needs to be registered in IAM before unified permission management can be performed through IAM.

[0037] Optionally,

[0038] IAM refers to authentication and access management, which centrally manages user, resource and permission information and provides unified authentication capabilities.

[0039] Compared with the prior art, the present invention has the following beneficial effects:

[0040] In an embodiment of the present invention, a distributed storage scheme for permission metadata is proposed, which is composed of distributed storage of permission metadata, an agent for collecting and reporting permission metadata, a change execution service liquibase-server and a permission database. The permission metadata of each business application is managed by each business application itself according to the agreed rules, such as being uniformly placed in the iam folder under the root path of the application, providing an agent package, and integrating it into each microservice application. After the microservice application is started, the agent runs automatically. The agent is responsible for reading the permission metadata change file from the agreed iam path and submitting it to the change execution service liquibase-server, and then executing the change file into the iam permission database through liquibase. This scheme eliminates the strong dependence of business applications on IAM. Business applications add and change permission metadata without relying on IAM to release through iterative versions, making the management of permission metadata simpler and more flexible. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0042] Figure 1 It is a schematic diagram of a method for implementing distributed initialization of rights metadata provided by an embodiment of the present invention;

[0043] Figure 2 It is a flowchart of a method for implementing distributed initialization of rights metadata provided by an embodiment of the present invention. Specific implementation methods

[0044] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0045] See also Figure 1 The present invention provides a technical solution: a method for implementing distributed initialization of rights metadata, the method comprising:

[0046] The process of distributed storage of permission metadata, by creating an iam folder under the root path of each application, is used to store the permission metadata change files of the application;

[0047] The agent process for collecting and reporting permission metadata. The agent is a relatively single and independent program code running in the application, mainly used to collect the content of the permission metadata change files in the iam folder under the root path of the application and report it to the liquibase-server;

[0048] The process of the change execution service liquibase-server. After receiving the change file, Liquibase-server executes the change file into the permission database of iam through liquibase.

[0049] In the process of distributed storage of permission metadata, the carrier of its permission metadata is an xml file that conforms to the liquibase specification;

[0050] Its file format is as follows:

[0051] <?xml version="1.0" encoding="UTF-8"?>

[0052] <databaseChangeLog

[0053] <changeSet author="xxx" id="xxx">

[0054] <insert tableName="Permission metadata data table name">

[0055] <column name="Column name" value="Value" / >

[0056] ……

[0057]

[0058]

[0059] 。

[0060] The data that each service application needs to initialize includes its own business data and permission metadata. Its own business data needs to be initialized to the database it uses, and its permission metadata needs to be initialized to the IAM (access management) database. The initialization solution for its own business data is relatively mature and can be implemented directly using liquibase. The permission metadata that needs to be initialized to other databases is uniformly stored in the IAM application and initialized by IAM. If a business application adds a new interface, it is necessary to synchronously register a copy of the permission metadata in IAM. If the business application needs to release a new version, then IAM needs to release the version synchronously.

[0061] The permission metadata of each business application is managed by each business application according to the agreed rules, such as being placed in the iam folder under the root path of the application.

[0062] In the process of collecting and reporting permission metadata, the agent is expressed as a jar package in the Java platform. The application only needs to add the jar package to the application, and the agent will be started when the application is started. The agent reports and notifies the liquibase-server of the changes in the execution permission metadata. The liquibase-server will return an indicator of success or failure.

[0063] Provide an agent package and integrate it into each microservice application. After the microservice application is started, the agent runs automatically. The agent is responsible for reading the permission metadata change file from the agreed iam path and submitting it to the change execution service liquibase-server.

[0064] During the process of collecting and reporting permission metadata, the agent supports automatic retry. If the liquibase-server fails to execute, the agent will retry again after a period of time (such as 60 seconds) until it succeeds or times out (if the retry is still successful after 24 hours of application startup, it will not retry again).

[0065] During the change execution service liquibase-server process, the Liquibase-server is mainly responsible for receiving the permission metadata change file reported by the agent, and further executing it into the IAM database through the open source tool liquibase toolkit.

[0066] When changing the execution service liquibase-server, the main logic is as follows:

[0067] Receive the liquibase change files uploaded by the service application, and store the change files of each service application in a separate path. For example, the change file storage path of the cloud server is db / changelog / iam / master / ecs, and the change file storage path of the relational database is db / changelog / iam / master / rds.

[0068] First, obtain the link to the IAM permission database.

[0069] Then execute the liquibase change file in the specified path to the IAM permission database through the liquibase tool interface.

[0070] Then the execution result is fed back to the caller.

[0071] Liquibase is an open source database refactoring tool for tracking, managing, and applying database changes. It saves all database changes (including structure and data) in XML files for easy version control.

[0072] In the permission database process, each application resource, such as interface, URL, menu, etc., needs to be registered in IAM before unified permission management can be performed through IAM.

[0073] IAM refers to authentication and access management, which centrally manages user, resource and permission information and provides unified authentication capabilities.

[0074] This solution proposes a distributed storage solution for permission metadata, which is composed of distributed storage of permission metadata, an agent for collecting and reporting permission metadata, a change execution service liquibase-server, and a permission database. The permission metadata of each business application is managed by each business application according to the agreed rules, such as being placed in the iam folder under the root path of the application. An agent package is provided and integrated into each microservice application. After the microservice application is started, the agent runs automatically. The agent is responsible for reading the permission metadata change file from the agreed iam path and submitting it to the change execution service liquibase-server, and then executing the change file into the iam permission database through liquibase. This solution eliminates the strong dependence of business applications on IAM. Business applications can add or change permission metadata without relying on IAM to release iterative versions, making the management of permission metadata simpler and more flexible.

[0075] The information interaction, execution process and other contents between the units in the above-mentioned device are based on the same concept as the embodiment of the method of the present invention. For specific contents, please refer to the description in the embodiment of the method of the present invention, and no further description is given here.

[0076] The present invention also provides a rights metadata distributed initialization device, which stores instructions for causing a computer to execute the rights metadata distributed initialization method as described herein. Specifically, a system or device equipped with a storage medium can be provided, on which a software program code for implementing the functions of any of the above embodiments is stored, and a computer (or CPU or MPU) of the system or device is enabled to read and execute the program code stored in the storage medium.

[0077] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute a part of the present invention.

[0078] The storage medium embodiments for providing the program code include a floppy disk, a hard disk, a magneto-optical disk, an optical disk (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), a magnetic tape, a non-volatile memory card, and a ROM. Alternatively, the program code can be downloaded from a server computer by a communication network.

[0079] In addition, it should be clear that the functions of any of the above embodiments can be implemented not only by executing the program code read by the computer, but also by enabling an operating system operating on the computer to complete part or all of the actual operations based on instructions from the program code.

[0080] In addition, it can be understood that the program code read from the storage medium is written to a memory provided in an expansion board inserted into the computer or written to a memory provided in an expansion unit connected to the computer, and then based on the instructions of the program code, a CPU installed on the expansion board or the expansion unit is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above-mentioned embodiments.

[0081] It should be noted that not all steps and modules in the above-mentioned processes and system structure diagrams are necessary, and some steps or modules can be ignored according to actual needs. The execution order of each step is not fixed and can be adjusted as needed. The system structure described in the above-mentioned embodiments can be a physical structure or a logical structure, that is, some modules may be implemented by the same physical entity, or some modules may be implemented by multiple physical entities, or some components in multiple independent devices may be implemented together.

[0082] In the above embodiments, the hardware unit can be realized by mechanical method or electrical method. For example, a hardware unit can include permanent special circuit or logic (such as special processor, FPGA or ASIC) to complete the corresponding operation. The hardware unit can also include programmable logic or circuit (such as general-purpose processor or other programmable processor), which can be temporarily set by software to complete the corresponding operation. Concrete implementation method (mechanical method or special permanent circuit or temporary circuit) can be determined based on cost and time consideration.

[0083] The present invention is shown and described in detail above through the accompanying drawings and preferred embodiments. However, the present invention is not limited to these disclosed embodiments. Based on the above multiple embodiments, those skilled in the art can know that the code review methods in the above different embodiments can be combined to obtain more embodiments of the present invention, and these embodiments are also within the protection scope of the present invention.

Claims

1. An implementation method for distributed initialization of permission metadata, characterized in that, the implementation method for distributed initialization of permission metadata includes: The process of distributed storage of permission metadata, by creating an iam folder under the root path of each application to store the permission metadata change files of the application; The agent process for collecting and reporting permission metadata. The agent is a relatively single and independent program code running in the application, used to collect the content of the permission metadata change files in the iam folder under the root path of the application and report it to the liquibase-server; The change execution service liquibase-server process. After receiving the change file, Liquibase-server executes the change file into the permission database of IAM through liquibase; The permission database process, where all the permission metadata managed by IAM is centrally stored in the permission database.

2. The implementation method for distributed initialization of permission metadata according to claim 1, characterized in that: In the process of distributed storage of the permission metadata, the carrier of the permission metadata is an xml file that conforms to the liquibase specification; Its file format is as follows: <?xml version="1.0" encoding="UTF-8"? > <databasechangelog>< / databasechangelog> <changeSet author="xxx" id="xxx"> <insert tableName="Permission metadata data table name"> <column name="Column name" value="Value" / > …… 。 3. The implementation method for distributed initialization of permission metadata according to claim 1, characterized in that: In the agent process for collecting and reporting permission metadata, the agent is in the form of a jar package in the Java platform. The application only needs to add the jar package to the application, and the agent will start with the startup of the application. And the agent reports and notifies the liquibase-server to execute the change of the permission metadata, and the liquibase-server will return an indication of success or failure of the execution.

4. The implementation method for distributed initialization of permission metadata according to claim 3, characterized in that: In the agent process for collecting and reporting permission metadata, the Agent supports automatic retry. If the execution of the liquibase-server fails, the agent will retry again after a period of time until it succeeds or times out.

5. The implementation method for distributed initialization of permission metadata according to claim 1, characterized in that: In the change execution service liquibase-server process, the Liquibase-server is responsible for receiving the permission metadata change files reported by the agent and further executing them into the IAM database through the open-source tool liquibase toolkit.

6. The method for implementing distributed initialization of rights metadata according to claim 1, Features: The logic of the change execution service liquibase-server is as follows: Receive the liquibase change files uploaded by the service application, store each service application's change files in a separate path, and then obtain the link to the IAM permission database; Execute the liquibase change file in the specified path to the IAM permission database through the liquibase tool interface; Feedback the execution result to the caller.

7. The method for implementing distributed initialization of rights metadata according to claim 1, Features: Liquibase is an open source database refactoring tool for tracking, managing, and applying database changes. It saves all database changes in XML files for easy version control.

8. The method for implementing distributed initialization of rights metadata according to claim 1, Features: In the process of the permission database, the application resources of interfaces, URLs, and menus need to be registered in IAM before unified permission management can be performed through IAM.

9. The method for implementing distributed initialization of rights metadata according to claim 1, Features: The IAM refers to authentication and access management, which centrally manages user, resource and permission information and provides unified authentication capabilities.

Images