A chain-of-responsibility-based access control method and system

Abstract

This invention belongs to the field of access control and provides a method and system for access control based on a chain of responsibility. The method includes: creating a session based on user information and obtaining all available permissions for the user; querying the chain of responsibility related to the user from the chain of responsibility table, and filtering all available permissions based on organization, role, and permission information to obtain the user's final permissions; the creation of the chain of responsibility includes: establishing and storing an RBAC permission model containing a set of users, a set of organizations, a set of roles, and a set of permissions; assigning IDs to users using the RBAC permission model, assigning organizational relationships to users, assigning role relationships to users, and obtaining role permissions based on roles; and constructing a chain of responsibility based on the assignment relationships between users and organizations, users and roles, and roles and permissions.

Description

Technical Field

[0001] This invention belongs to the field of access control, and particularly relates to a permission access control method and system based on the chain of responsibility. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] Due to its advantages such as flexibility, ease of management, and policy neutrality, Role-Based Access Control (RBAC) has become the most widely used access control model in enterprise applications. The RBAC model is centered on roles. Instead of directly granting various permissions for system operations to specific users, it establishes a set of roles between the user set and the permission set, with each role corresponding to a set of permissions. Once a user is assigned an appropriate role, that user possesses all the access permissions for that role. The advantage of this approach is that it eliminates the need to assign permissions every time a user is created; only the corresponding role needs to be assigned. Furthermore, changes to role permissions are far less frequent than changes to user permissions. This greatly simplifies user permission management and reduces the complexity of access control.

[0004] While the RBAC model boasts numerous advantages and has been widely adopted, it suffers from limitations in supporting dynamic and fine-grained authorization. To address these shortcomings, and with the deepening of research and application of the RBAC access control model, it has been continuously improved and expanded, including: the location-based LRBAC model, which uses the current location to determine accessible resources and is widely used for access control in wireless mobile devices; the task-based TRBAC model, which places tasks on an equal footing with roles, associating roles with permissions through tasks, and is used for access control in collaborative work; and the attribute-based ARBAC model, where attributes are characteristics of roles, and attribute values ​​describe the actual state and specific characteristics of a role.

[0005] However, the relationships between users, roles, and permissions in the RBAC model are statically specified, making it impossible to dynamically match the relationships between users and roles, or roles and permissions, and thus failing to adequately meet dynamically changing system requirements. For example, in the education sector, education service providers sell different functional modules to different schools. Schools with dormitories might purchase dormitory management modules, schools with attendance requirements might purchase attendance modules, and so on. This necessitates that the system functional modules accessible to school administrators differ across schools, requiring dynamic matching of user permissions based on changing needs. Another example: User U1 is a teacher at school S1, and their child attends school S2, where they are a parent. Although User U1 holds both teacher and parent roles, they are required not to view teaching resources or other teacher-related functions at school S2. This necessitates dynamically matching user permissions based on their organizational affiliation.

[0006] Secondly, the RBAC model does not effectively support fine-grained authorization. It relies on adding numerous roles with varying access permissions to achieve fine-grained authorization and access control, significantly increasing management costs and complexity, and easily leading to role explosion. For example, in the education sector, education service providers may have different partners when promoting products in different regions. These partners, while acting as "agents," are only allowed access to and manipulation of data from the schools they are responsible for. Within schools, each homeroom teacher is only allowed access to information for the classes they are responsible for. Within education authorities, the same department may have different responsibilities in different regions. Simply using roles for access control cannot meet these fine-grained access control requirements. Customizing different roles for each region and school lacks flexibility and introduces management complexity, easily leading to a surge in the number of roles. Summary of the Invention

[0007] To address the technical problems existing in the background art, this invention provides a chain-of-responsibility-based access control method and system. It extends the RBAC model by introducing the concepts of organization and responsibility, enabling fine-grained authorization and access control of permissions. Simultaneously, it utilizes the chain of responsibility to achieve dynamic authorization between users, roles, and permissions. This retains the advantages of the RBAC model, such as flexibility and ease of management, while overcoming its shortcomings in supporting dynamic and fine-grained authorization.

[0008] To achieve the above objectives, the present invention adopts the following technical solution:

[0009] The first aspect of the present invention provides a chain-of-responsibility-based access control method.

[0010] A chain-of-responsibility-based access control method includes:

[0011] Based on user information, create a session and obtain all available permissions for the user;

[0012] The responsibility chain is retrieved from the responsibility chain list to find the responsibility chain related to the user, and all available permissions are filtered according to the organization, role and permission information to obtain the user's final permissions;

[0013] The creation of the chain of responsibility includes: establishing and saving an RBAC permission model containing a set of users, a set of organizations, a set of roles, and a set of permissions; using the RBAC permission model to assign IDs to users, assign organizational relationships to users, assign role relationships to users, and obtain role permissions based on roles; and constructing a chain of responsibility based on the assignment relationships between users and organizations, the assignment relationships between users and roles, and the allocation relationships between roles and permissions.

[0014] A second aspect of the present invention provides a chain-of-responsibility-based access control system.

[0015] A chain-of-responsibility-based access control system includes:

[0016] The data acquisition module is configured to: create a session based on user information and acquire all available permissions for the user;

[0017] The permission determination module is configured to: query the responsibility chain related to the user from the responsibility chain list, and filter all available permissions according to organization, role and permission information to obtain the user's final permissions;

[0018] The responsibility chain generation module is configured to: create the responsibility chain by: establishing and saving an RBAC permission model containing a user set, an organization set, a role set, and a permission set; assigning IDs to users using the RBAC permission model, assigning organizational relationships to users, assigning role relationships to users, and obtaining role permissions based on roles; and constructing the responsibility chain based on the assignment relationships between users and organizations, users and roles, and roles and permissions.

[0019] A third aspect of the present invention provides a computer-readable storage medium.

[0020] A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of the chain-of-responsibility-based access control method as described in the first aspect above.

[0021] A fourth aspect of the present invention provides a computer device.

[0022] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the chain-of-responsibility-based access control method as described in the first aspect above.

[0023] Compared with the prior art, the beneficial effects of the present invention are:

[0024] This invention extends the RBAC permission model, solving the problem that the RBAC permission model cannot well support fine-grained authorization and dynamic access control, and does not cause role explosion.

[0025] Compared to other RBAC extension models, the LRBAC model is suitable for wireless mobile devices, and the TRBAC model is suitable for collaborative work scenarios. The organizational elements and responsibility concepts introduced in this invention are more suitable for general enterprise business system application scenarios, especially in the education field.

[0026] The ARBAC model, or its extended versions, adds the concept of attributes, requiring additional attribute definitions for elements within the model, thus increasing the complexity of access control. The responsibility concept introduced in this invention is an abstraction of the existing relationships between elements in the model and does not add additional complexity to access control. Although the organizational element introduced in this invention is an additional element compared to the original RBAC model, the organization is an essential element of an enterprise business system, and therefore does not actually add any additional management complexity. Attached Figure Description

[0027] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0028] Figure 1 This is a schematic diagram of an extended permission access model shown in an embodiment of the present invention;

[0029] Figure 2 This is a schematic diagram of the system database model shown in an embodiment of the present invention;

[0030] Figure 3 This is a flowchart illustrating the chain of responsibility generation in an embodiment of the present invention;

[0031] Figure 4 This is a flowchart illustrating the user permission verification process in an embodiment of the present invention. Detailed Implementation

[0032] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0033] It should be noted that the following detailed description is illustrative and intended to provide further explanation of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0034] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0035] It should be noted that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and systems according to various embodiments of this disclosure. It should be noted that each block in a flowchart or block diagram may represent a module, segment, or portion of code, which may include one or more executable instructions for implementing the logical functions specified in the various embodiments. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutively represented blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, may be implemented using a dedicated hardware-based system that performs the specified functions or operations, or using a combination of dedicated hardware and computer instructions.

[0036] Example 1

[0037] like Figure 1As shown, this embodiment provides a chain-of-responsibility-based access control method. This embodiment uses the application of this method to a server as an example for illustration. It is understood that this method can also be applied to terminals, and can also be applied to systems including terminals, servers, and other components, and implemented through interaction between the terminal and the server. The server can be an independent physical server, a server cluster composed of multiple physical servers, or a distributed system. It can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network servers, cloud communication, middleware services, domain name services, CDN security services, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited herein. In this embodiment, the method includes the following steps:

[0038] Based on user information, create a session and obtain all available permissions for the user;

[0039] The responsibility chain is retrieved from the responsibility chain list to find the responsibility chain related to the user, and all available permissions are filtered according to the organization, role and permission information to obtain the user's final permissions;

[0040] The creation of the chain of responsibility includes: establishing and saving an RBAC permission model containing a set of users, a set of organizations, a set of roles, and a set of permissions; using the RBAC permission model to assign IDs to users, assign organizational relationships to users, assign role relationships to users, and obtain role permissions based on roles; and constructing a chain of responsibility based on the assignment relationships between users and organizations, the assignment relationships between users and roles, and the allocation relationships between roles and permissions.

[0041] As one or more implementation methods, the organization includes: real organizational structures, departments, administrative regions, and virtual organizations.

[0042] The extended access control model in this embodiment is as follows: Figure 1 As shown.

[0043] This embodiment extends the RBAC model by adding organizational elements to the original core element set. Organizational elements are abstractions of real-world organizations, including real organizations and departments (education bureaus, offices, schools, classes, etc.), administrative regions (provinces, cities, districts, counties, etc.), and virtual groups (expert groups, attendance groups, etc.). Organizations have hierarchical relationships, generally in a tree structure, with a one-to-many relationship between higher and lower-level organizations. The introduction of organizational elements makes the access control model of this invention more consistent with actual user scenarios and facilitates fine-grained authorization.

[0044] This embodiment abstracts the allocation relationships between elements in the model into responsibilities, which can be viewed as a delegation relationship. For example, the allocation relationship between a user and a role can be seen as the user being delegated the responsibility of the role. A responsibility chain is a chain formed by combining multiple responsibilities, through which the relationships between organizations, users, roles, and permissions can be dynamically matched.

[0045] The chain-of-responsibility (LOR)-based access control method adds a "chain-of-responsibility filtering" process to the original static permission verification process of the RBAC model. This enables dynamic activation and reduction of session role permissions. The session is a crucial concept in the RBAC model; activating roles through sessions allows the model to better support the principle of least privilege. By introducing the chain of responsibility, the activation process can be dynamically determined, making the model more flexible and supporting dynamic authorization. Through LIR-based permission filtering, all permissions of roles within a session are constrained and restricted to obtain the final usable permissions, improving the security and dynamism of the access process.

[0046] Model definition

[0047] The core elements USERS, ROLES, SESSIONS, OPS, RES, and PERMS are defined in the same way as in the RBAC model, representing the collection of users, roles, sessions, operations, resources, and permissions, respectively.

[0048] User set: USERS = {U1, U2, ..., Un}.

[0049] Role set: ROLES = {R1, R2, ..., Rn}.

[0050] Session set: SESSIONS = {S1, S2, ..., Sn}.

[0051] Operation set: OPS = {Op1, Op2, ..., Opn}.

[0052] Resource set: RES = {Re1, Re2, ..., Ren}.

[0053] Permission set: PERMS = 2 (OPS×RES) .

[0054] A new core element, ORGS, has been added, representing a collection of organizations.

[0055] Organization set: ORGS = {Org1, Org2, ..., Orgn}.

[0056] Responsibilities represent the allocation relationships between elements, including the assignment relationship between users and organizations (OU), the assignment relationship between users and roles (UR), and the allocation relationship between roles and permissions (RP).

[0057] This indicates a many-to-many user organization assignment relationship.

[0058] This indicates a many-to-many user role assignment relationship.

[0059] This indicates a many-to-many role permission allocation relationship.

[0060] This indicates that responsibility is the union of the distribution relationships between the elements.

[0061] A chain of responsibility (CoR) is a chain formed by combining multiple responsibilities.

[0062] Set of chains of responsibility: CoR = 2 (OU×UR×RP) .

[0063] This embodiment extends the access permission verification part of the RBAC model. In addition to using the existing CheckAccess function for access permission verification, a new ResponsibilityFilter function is added to filter permissions through the chain of responsibility and return the final available permissions for each specific session.

[0064] This indicates a one-to-many user session login relationship.

[0065] This indicates a one-to-many session role activation relationship.

[0066] Function definition

[0067] The assigned_orgs(u) function represents the set of organizations mapped to the user, where o ∈ ORGS | (org, u) ∈ OU.

[0068] The assigned_roles(u) function maps to the set of roles for the user, where r ∈ ROLES | (u, r) ∈ UR.

[0069] The assigned_permissions(r) function represents the set of permissions mapped to the role, where p ∈ PRMS | (p, r) ∈ RP.

[0070] has_cor(u) = {cor∈CoR|(u|→(ou, ur, rp))∈CoR}, which represents the set of responsibility chains mapped to this user.

[0071] user_session(u) = {s∈SESSIONS|(s,u)∈US}, which represents the set of sessions mapped to a user after logging into the system.

[0072] available_permissions(s) = {p∈PRMS|((s,r)∈SR)→((r,p)∈RP)}, which represents the set of all available permissions for a user in a session.

[0073] final_permissions(s) = {p∈PRMS|((s,u)∈US)→((ou,ur,rp)∈CoR)}, which represents the final set of permissions for a user in a session.

[0074] Create user functions:

[0075]

[0076] Assign user organization function:

[0077]

[0078] User role assignment function:

[0079]

[0080]

[0081] Function to assign role permissions:

[0082]

[0083] Functions that generate chain of responsibility:

[0084]

[0085]

[0086] User logs in and retrieves all available permission functions for the session:

[0087]

[0088] The chain of responsibility (LOR) permission filtering system consists of a `ResponsibilityFilter` function and several `FILTER` functions. The `ResponsibilityFilter` selects the desired filter for each user: `ResponsibilityFilter(session:SESSION) → {F1, F2, F3, ..., F}`. n};CoR={F1, F2, F3,…,Fn} is the set of responsibility chains composed of responsibility filters, and F i : SESSION×OPS×RES×CoR→{TRUE, FALSE}, where TRUE indicates permission to the resource, and FALSE indicates no permission to the resource.

[0089]

[0090]

[0091] The access control method based on the chain of responsibility described in this embodiment mainly includes a user authentication module, an access control module, a user management module, a role management module, a resource management module, an organization management module, and a chain of responsibility parsing module.

[0092] System database model such as Figure 2 As shown.

[0093] The tables in the database model are described below:

[0094] (1) Core element table: includes Organizations, Users, Roles, Resources, Operations, and Permissions, which respectively record information about core elements such as organizations, users, roles, resources, operations, and permissions.

[0095] (2) Responsibility Table: Includes UserOrgRelations, UserRoleRelations, and RolePermRelations, which respectively record information on the assignment relationship between users and organizations, the assignment relationship between users and roles, and the allocation relationship between roles and permissions.

[0096] (3) Chain of Responsibility: The Chain of Responsibility record information about the chain of responsibilities.

[0097] Based on the above data table correspondence, user permissions can be dynamically verified according to the chain of responsibility to achieve the purpose of access control.

[0098] The main logic implementation methods of the system, such as Figure 3 As shown:

[0099] (1) Create users and generate a chain of responsibility

[0100] Step 1: Call the AddUser(user:NAME) function to create a user instance, assign a user_id to the user, and write it to the Users table.

[0101] Step 2: Call the AssginOrg(org, user:NAME) function to assign the user's organizational affiliation and write it to the UserOrgRelations table.

[0102] Step 3: Call the AssignRole(role, user:NAME) function to assign the user's role relationships and write them to the UserRoleRelations table.

[0103] Step 4: Call the `assigned_permissions(r)` function to obtain the role permission relationships. If the role has not yet been assigned permissions, you need to first call the `AssignPermission(res, oper, role:NAME)` function to assign role permission relationships and write them to the `RolePermRelations` table, and then obtain the role permission relationships. In other words, if the role has not yet been assigned permissions, assign role permission relationships to the role.

[0104] Step 5: Call the GenerateCoR(ou,ur,rp,user:NAME) function to generate the chain of responsibility and write it to the ChainOfResponsibility table.

[0105] (2) User permission verification, such as Figure 4 As shown:

[0106] Step 1: User login. Query user information from the User table and verify account and password.

[0107] Step 2: If login is successful, call the GenerateSession(user) function to create a session. Based on the responsibility relationships in the UserOrgRelations, UserRoleRelations, and RolePermRelations tables, query the organization, role, and permission information and store them in the session.

[0108] Step 3: Call the available_permissions(session) function to obtain all available permissions for the user.

[0109] Step 4: Call the ResponsibilityFilter(session) function to query the chain of responsibility from the ChainOfResponsibility table and filter permissions based on the organization, role, and permission information stored in the session.

[0110] Step 5: Call the final_permissions(s) function to obtain the user's final permissions.

[0111] Step 6: Call the CheckAccess function to verify permissions.

[0112] Take fine-grained authorization and dynamic access control for homeroom teachers in the education field as an example. Teacher A is the homeroom teacher of Class 1, Grade 5 at School S. When creating Teacher A's account, a relationship needs to be established between Teacher A's account and the organization "Class 1, Grade 5" at School S, and between Teacher A's account and the role of homeroom teacher. The homeroom teacher role has permissions such as class attendance and student leave requests. After assigning these relationships, a responsibility chain is created in the system: "Class 1, Grade 5, School S → Teacher A → Homeroom Teacher → {Class Attendance, Student Leave, ...}". Simultaneously, Teacher A is also a staff member of School S, possessing permissions such as staff attendance and teaching resources. After assigning these relationships, a responsibility chain is also created in the system: "School S → Teacher A → Staff Member → {Staff Attendance, Teaching Resources, ...}". After logging into the system, Teacher A has all the permissions of both a homeroom teacher and a staff member. However, when accessing the "Class Attendance" or "Student Leave" modules, through the filtering of the responsibility chain, they can only see data from Class 1, Grade 5. When accessing the "Teaching Resources" module, one can view all the teaching resources for School S. A similar scenario is someone who is a faculty member in School S1 and a parent in School S2, etc.

[0113] This invention abstracts the allocation relationship between elements in the access control model into responsibilities, and forms a responsibility chain by combining several different responsibilities. The relationship between organizations, users, roles and permissions is dynamically allocated through the responsibility chain.

[0114] This invention dynamically determines the activation process of a role through a chain of responsibility, and constrains and restricts all permissions of a role in a session, filtering out the final available permissions, which can support fine-grained authorization and dynamic access control.

[0115] Example 2

[0116] This embodiment provides a permission access control system based on the chain of responsibility.

[0117] A chain-of-responsibility-based access control system includes:

[0118] The data acquisition module is configured to: create a session based on user information and acquire all available permissions for the user;

[0119] The permission determination module is configured to: query the responsibility chain related to the user from the responsibility chain list, and filter all available permissions according to organization, role and permission information to obtain the user's final permissions;

[0120] The responsibility chain generation module is configured to: create the responsibility chain by: establishing and saving an RBAC permission model containing a user set, an organization set, a role set, and a permission set; assigning IDs to users using the RBAC permission model, assigning organizational relationships to users, assigning role relationships to users, and obtaining role permissions based on roles; and constructing the responsibility chain based on the assignment relationships between users and organizations, users and roles, and roles and permissions.

[0121] It should be noted that the data acquisition module, permission determination module, and chain of responsibility generation module described above are the same examples and application scenarios implemented in the steps of Embodiment 1, but are not limited to the content disclosed in Embodiment 1. It should also be noted that these modules, as part of the system, can be executed in a computer system such as a set of computer-executable instructions.

[0122] Example 3

[0123] This embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the chain-of-responsibility-based access control method as described in Embodiment 1 above.

[0124] Example 4

[0125] This embodiment provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps in the chain-of-responsibility-based access control method described in Embodiment 1 above.

[0126] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0127] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0128] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0129] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0130] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0131] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A chain-of-responsibility-based access control method, characterized in that, include: Based on user information, create a session and obtain all available permissions for the user; The responsibility chain is retrieved from the responsibility chain list to find the responsibility chain related to the user, and all available permissions are filtered according to the organization, role and permission information to obtain the user's final permissions; The creation of the chain of responsibility includes: establishing and saving an RBAC permission model containing a set of users, a set of organizations, a set of roles, and a set of permissions; using the RBAC permission model to assign IDs to users, assign organizational relationships to users, assign role relationships to users, and obtain role permissions based on roles; if a role has not yet been assigned permissions, assign role permission relationships to the role; and constructing a chain of responsibility based on the assignment relationships between users and organizations, users and roles, and roles and permissions, and writing it into the chain of responsibility list. Functions that generate chain of responsibility: GenerateCoR(ou, ur, rp, user: NAME) user∈USERS; ou∈OU; ur∈UR; rp∈RP; cor=(ou,ur,rp); (cor|→user)∉CoR; CoR´ = CoR\{cor|→user}; has_cor´ = has_cor\{user|→has_cor(user)} ∪ {user|→(has_cor(user)∪{cor})}; A chain of responsibilities is a chain formed by combining multiple responsibilities, through which the relationships between organizations, users, roles and permissions are dynamically matched; The chain-of-responsibility-based access control method adds a "chain-of-responsibility-filtering-permissions" process without changing the original static permission verification process of the RBAC model, thereby enabling dynamic activation and dynamic reduction of session role permissions. The filtering process employs filtering functions and several duty-based filters, with different users selecting different filters. The filtering function selects the desired filter for each user: ResponsibilityFilter(session:SESSION) → {F1, F2, F3, ..., F...} n };CoR ={F1, F2, F3,…,F n } is the set of responsibility chains composed of responsibility filters, and F i : SESSION × OPS × RES × CoR → {TRUE, FALSE}; The core elements USERS, ROLES, SESSIONS, OPS, RES, and PERMS are defined in the same way as in the RBAC model, representing the collection of users, roles, sessions, operations, resources, and permissions, respectively. User set: USERS = { U1, U2, ..., Un}; Character set: ROLES = { R1, R2, ..., Rn}; Session set: SESSIONS = { S1, S2, ..., Sn}; Operation set: OPS = {Op1, Op2, ..., Opn}; Resource set: RES = {Re1, Re2, ..., Ren}; Permission set: PERMS = 2 ( OPS × RES) ; A new core element, ORGS, has been added to represent a collection of organizations; Organization set: ORGS = { Org1, Org2, ..., Orgn}; A value of TRUE indicates that the user has permission to access the resource; otherwise, it indicates that the user does not have permission to access the resource. Responsibilities represent the allocation relationships between various elements, including the assignment relationship between users and organizations (OU), the assignment relationship between users and roles (UR), and the allocation relationship between roles and permissions (RP). This indicates a many-to-many user organization assignment relationship; This indicates a many-to-many user role assignment relationship; This indicates a many-to-many role permission allocation relationship; This indicates that the responsibilities are the union of the distribution relationships among the elements; Chain of Responsibility (CoR) is a chain formed by combining multiple responsibilities; Set of chains of responsibility: CoR = 2 ( OU × UR × RP) .

2. The access control method based on chain of responsibility according to claim 1, characterized in that, The organizations mentioned include: real organizations, departments, administrative regions, and virtual organizations.

3. A chain-of-responsibility-based access control system, employing the chain-of-responsibility-based access control method as described in claim 1, characterized in that, include: The data acquisition module is configured to: create a session based on user information and acquire all available permissions for the user; The permission determination module is configured to: query the responsibility chain related to the user from the responsibility chain list, and filter all available permissions according to organization, role and permission information to obtain the user's final permissions; The responsibility chain generation module is configured to: create the responsibility chain by: establishing and saving an RBAC permission model containing a user set, an organization set, a role set, and a permission set; assigning IDs to users, assigning organizational relationships to users, assigning role relationships to users, and obtaining role permissions based on roles; and constructing a responsibility chain based on the assignment relationships between users and organizations, users and roles, and roles and permissions. The core elements USERS, ROLES, SESSIONS, OPS, RES, and PERMS are defined in the same way as in the RBAC model, representing the collection of users, roles, sessions, operations, resources, and permissions, respectively. User set: USERS = { U1, U2, ..., Un}; Character set: ROLES = { R1, R2, ..., Rn}; Session set: SESSIONS = { S1, S2, ..., Sn}; Operation set: OPS = {Op1, Op2, ..., Opn}; Resource set: RES = {Re1, Re2, ..., Ren}; Permission set: PERMS = 2 ( OPS × RES) ; A new core element, ORGS, has been added to represent a collection of organizations; Organization set: ORGS = { Org1, Org2, ..., Orgn}; Responsibilities represent the allocation relationships between various elements, including the assignment relationship between users and organizations (OU), the assignment relationship between users and roles (UR), and the allocation relationship between roles and permissions (RP). This indicates a many-to-many user organization assignment relationship; This indicates a many-to-many user role assignment relationship; This indicates a many-to-many role permission allocation relationship; This indicates that the responsibilities are the union of the distribution relationships among the elements; Chain of Responsibility (CoR) is a chain formed by combining multiple responsibilities; Set of chains of responsibility: CoR = 2 ( OU × UR × RP) .

4. The access control system based on chain of responsibility according to claim 3, characterized in that, The organizations mentioned include: real organizations, departments, administrative regions, and virtual organizations.

5. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps in the chain-of-responsibility-based access control method as described in any one of claims 1-2.

6. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the chain-of-responsibility-based access control method as described in any one of claims 1-2.

Images