A multi-tenant identity authentication and permission management method based on multi-factor authentication and ABAC model

Abstract

This invention relates to a multi-tenant authentication and access control method based on multi-factor authentication and the ABAC model, belonging to the field of power information security technology. It includes: adopting a distributed architecture comprising a master node and multiple edge nodes; establishing ABAC-based access control rules on the master node to achieve fine-grained access control for tenants and roles within tenants; distributing the access control rules to each edge node for access verification during business requests; establishing a multi-factor authentication mechanism on each edge node, setting up an authentication system combining multiple factors; setting up a dynamic access control adjustment mechanism and an auditing and monitoring mechanism; dynamically adjusting tenant permissions based on changes in tenant business or security incidents through the dynamic access control mechanism; and recording and monitoring business operations of the master node and each edge node through the auditing and monitoring mechanism. This invention is applicable to multi-tenant environments, improving the security of authentication and the accuracy of access control.

Description

Technical Field

[0001] This invention belongs to the field of power information security technology, and relates to a multi-tenant authentication and access control method based on multi-factor authentication and ABAC model. Background Technology

[0002] Existing multi-tenant identity authentication and access control systems have several significant shortcomings, primarily in insufficient authentication security, poor flexibility in access management, and slow response times. Currently, most multi-tenant systems still rely on traditional username + password authentication, making them vulnerable to brute-force attacks and password leaks. This renders the system ineffective against complex security threats. Furthermore, existing access management models commonly employ Role-Based Access Control (RBAC), which cannot flexibly address the access requirements of different tenants or roles in dynamic and complex business environments, often resulting in either "excessive permissions" or "insufficient permissions."

[0003] Furthermore, existing systems typically lack support for single sign-on (SSO) across tenant applications, resulting in isolated authentication and access control across multiple tenants, preventing users from seamlessly logging in between different tenant systems. Most multi-tenant systems also fail to fully automate dynamic permission adjustments, often relying on manual intervention, leading to slow response times in the event of security incidents and increasing potential security risks.

[0004] Especially in the power and energy industry, with the construction of enterprise-level measurement data centers, the data scale has reached trillions, covering tens of millions of user devices across provinces. Existing unified identity authentication systems (4A platforms) primarily address the issue of unified login entry at the system level. However, when facing cross-city data sharing and granular access control based on data classification (core / important / general), they often lack dynamic decision-making capabilities based on data attributes. Furthermore, for highly sensitive measurement data, there is a lack of a secondary enhanced authentication mechanism after basic 4A authentication, making it difficult to meet the stringent protection requirements of the Data Security Law for core data.

[0005] A patent application filed on May 10, 2022 (application number: 2022105043351) proposes a multi-tenant identity authentication system, primarily providing a solution for cross-tenant single sign-on (SSO), supporting single sign-on across different tenant identity authentication servers. However, the existing technology still has some problems: on the one hand, this system mainly relies on hardware devices for authentication and permission verification, leading to increased system complexity and maintenance costs; on the other hand, the cross-tenant single sign-on mechanism may have performance bottlenecks in practical applications, and its data isolation and dynamic permission adjustment functions for different tenants are still insufficient. Summary of the Invention

[0006] In view of this, the purpose of this invention is to provide a multi-tenant authentication and access control method based on multi-factor authentication and the ABAC model. By introducing multi-factor authentication and attribute-based access control (ABAC) model, the security of identity authentication is enhanced. At the same time, through dynamic access control and cross-tenant single sign-on mechanism, the problems of insufficient authentication security, poor access control flexibility, and insufficient support for cross-tenant single sign-on in the prior art are solved, thereby providing a secure, flexible and efficient multi-tenant identity authentication and access control solution.

[0007] To achieve the above objectives, the present invention provides the following technical solution: A multi-tenant authentication and access control method based on multi-factor authentication and ABAC model, the method comprising: It adopts a distributed architecture that includes a master node and multiple edge nodes; Establish ABAC-based permission management rules on the master node, define multi-dimensional attributes, and build a permission decision rule library to achieve fine-grained permission allocation for tenants and roles within tenants; distribute the established permission management rules to each edge node for permission verification when edge nodes make business requests. Establish a multi-factor authentication mechanism at each edge node, set up an authentication system that combines multiple factors, and dynamically adjust the combination of authentication factors according to the tenant's security level; In addition, a dynamic permission adjustment mechanism and an audit and monitoring mechanism are set up; through the dynamic permission adjustment mechanism, tenant permissions are dynamically adjusted when tenant business changes or security incidents occur; through the audit and monitoring mechanism, the business operations of the master node and each edge node are recorded and monitored.

[0008] Furthermore, the ABAC-based access control rules include: Define a multi-dimensional attribute system, setting tenant attributes, user attributes, resource attributes, and environment attributes; among them, tenant attributes include edge node identifier, function, and region; user attributes include user role information; resource attributes include the security level of resource data; and environment attributes include access source, access time, and network type. A permission decision rule base is constructed using rule engine technology. The rules are defined in the form of "IF-THEN", where IF is used for attribute matching and THEN is used to issue a notification that the operation can be performed after the attribute matching is successful. Set up a tenant isolation mechanism to associate tenant attributes with resource attributes, enabling one-to-one or one-to-many binding between tenants and resources, so that tenants can only access resources within their authorized scope; at the same time, introduce a permission mask mechanism to divide the permissions of different users within a tenant.

[0009] Furthermore, a storage strategy combining categorized storage and encryption protection is adopted to store multi-dimensional attribute data. Core attributes are stored in a relational database, while sensitive attributes are stored in an encrypted database. Sensitive attributes are processed using the AES-256 encryption algorithm before storage.

[0010] Furthermore, establishing a multi-factor authentication mechanism includes setting up an authentication system that combines multiple factors, including basic authentication factors, biometric enhancement factors, and dynamic token enhancement factors. The basic authentication factors include the tenant's unique identifier and password. The tenant's password is encrypted using the PBKDF2 algorithm and then stored. The biometric enhancement factor is the tenant's biometrics. The biometric enhancement factor is verified by a combination of local feature extraction and cloud-based encrypted comparison. The original biometric data is stored only locally on the tenant's terminal, while only the encrypted feature template is stored in the cloud. The dynamic token enhancement factor is either a hardware dynamic token or a software token; a hardware dynamic token is a dynamic verification code generated through a time synchronization algorithm; a software token is an event-triggered dynamic code, and each generated dynamic code is bound to the tenant's current login terminal IP to prevent the dynamic code from being used across terminals. Based on the three set factors, the security level of the tenant is preset, and different combinations of authentication factors are selected according to the tenant's security level.

[0011] The method for generating the hardware dynamic token includes defining a time counter. :

[0012] In the formula, The start time, For time step, The current time; a dynamic verification code generated based on a time counter. Represented as:

[0013] In the formula, For shared keys, The number of digits for the verification code; the Truncate function indicates from HMAC The integer value dynamically extracted from the hash value; This represents Secure Hash Algorithm 1. This represents the modulo operation, where the modulus is 10 raised to the power of d.

[0014] Furthermore, the dynamic permission adjustment mechanism includes event-driven permission adjustment and periodic detection-based permission adjustment; Event-driven permission adjustment includes a preset permission adjustment trigger event library. When the corresponding event in the permission adjustment trigger event library occurs, the permission adjustment operation is executed according to preset rules. Periodic detection-based permission adjustments include performing compliance checks on the permission configurations of all tenants at preset intervals, comparing the matching degree between the tenant's current business needs, security level and existing permission configurations, and automatically generating permission adjustment suggestions if permission redundancy or missing permissions are found. After confirmation by the tenant administrator, the adjustment operation is executed, or the adjustment is automatically completed according to the tenant's preset policy.

[0015] Furthermore, the auditing and monitoring mechanism includes collecting authentication logs, permission adjustment logs, and resource access logs in real time through access log collection tools, displaying key indicators using a visual monitoring platform, and automatically triggering alarms when the indicators exceed preset thresholds.

[0016] The beneficial effects of this invention are as follows: (1) The present invention significantly improves the security of identity authentication through a layered authentication mechanism, bringing a double security enhancement: On the one hand, by superimposing multiple factors to resist risks, the present invention adopts a three-level authentication system of basic authentication factor, biometric enhancement factor and dynamic token enhancement factor, which combines static password, dynamic token, biometrics and other multi-dimensional factors, greatly increases the difficulty of identity forgery, and significantly improves the security of identity authentication.

[0017] (2) This invention, based on the attribute-driven mechanism of the ABAC model, achieves precise adaptation of permission management. On the one hand, it supports precise authorization based on multi-dimensional attributes. By constructing a four-layer attribute system of "tenant-role-resource-environment," the basis for permission allocation is expanded from a single role to multiple dimensions such as tenant security level, data sensitivity, business type, and source environment, achieving dual precise control at the "resource level + operation level." On the other hand, tenants can customize authentication policies and permission rules through a visual interface within the system compliance framework, without relying on platform maintenance personnel. When the tenant's business scope expands, data access permission rules can be quickly adjusted, greatly improving the response efficiency to changes in tenant business.

[0018] (3) This invention constructs a dynamic permission adjustment mechanism to achieve automated adaptation driven by both "business" and "security". Real-time response is achieved through a dual-trigger mechanism: through two types of trigger conditions, namely "business change driven" (tenant type upgrade, data sensitivity adjustment) and "security event driven" (account leakage, abnormal access), change information is collected and permission rules are matched to complete the immediate update or temporary freezing of permissions. Business continuity is ensured through a circuit breaker and recovery mechanism: when a security incident occurs, only the high-risk permissions of the account involved (such as data export, permission change) are frozen, while basic permissions such as query are retained, avoiding business interruption caused by the traditional "one-size-fits-all" freezing method; after the security incident is resolved, the corresponding permissions are automatically restored, achieving a balance between "security protection" and "business continuity".

[0019] (4) One of the core pain points of multi-tenant environments is incomplete resource isolation, which easily leads to the problem of "tenants accessing other tenants' data without authorization." At the same time, existing technologies struggle to meet multi-dimensional compliance requirements such as information security standards and GDPR. This invention solves these problems through an integrated design: A dual isolation mechanism safeguards data boundaries: Employing a logical isolation architecture of "tenant ID + attribute tag," all data and resources are bound to a unique tenant ID. Simultaneously, attribute tags differentiate resources of varying sensitivity within a tenant, ensuring "complete data isolation between tenants and on-demand resource isolation within a tenant." Compared to traditional isolation methods that rely solely on tenant IDs, this invention reduces the risk of cross-tenant data access to near zero and improves resource isolation reliability by 90%.

[0020] Integrated compliance design reduces audit costs: By using mainstream compliance rule bases such as Cybersecurity Classified Protection 2.0 and GDPR, compliance verification is automatically performed during permission allocation and adjustment to ensure that permission configurations meet regulatory requirements; at the same time, audit logs covering the entire process of authentication, authorization, and change are generated, and the log retention time meets the minimum compliance period, supporting one-click export of audit reports.

[0021] Other advantages, objectives, and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination, or may be learned from practice of the invention. The objectives and other advantages of the invention can be realized and obtained through the following description. Attached Figure Description

[0022] To make the objectives, technical solutions, and advantages of the present invention clearer, the preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings, wherein: Figure 1 This is a structural block diagram of the multi-tenant authentication and access control method based on multi-factor authentication and ABAC model provided by the present invention; Figure 2This is a flowchart illustrating the business request process in Example 1. Detailed Implementation

[0023] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0024] The accompanying drawings are for illustrative purposes only and are schematic diagrams, not actual pictures. They should not be construed as limiting the invention. To better illustrate the embodiments of the invention, some parts in the drawings may be omitted, enlarged, or reduced, and do not represent the actual product dimensions. It is understandable to those skilled in the art that some well-known structures and their descriptions may be omitted in the drawings.

[0025] In the accompanying drawings of the embodiments of the present invention, the same or similar reference numerals correspond to the same or similar components. In the description of the present invention, it should be understood that if terms such as "upper," "lower," "left," "right," "front," and "rear" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the terms used to describe positional relationships in the drawings are only for illustrative purposes and should not be construed as limiting the present invention. For those skilled in the art, the specific meaning of the above terms can be understood according to the specific circumstances.

[0026] Traditional authentication methods and static access control mechanisms are insufficient to meet the security, flexibility, and dynamic adjustment requirements of multi-tenant systems. In particular, existing technologies fail to provide timely and automatic access control and effective resource isolation when faced with changes in tenant business needs and security incidents. This invention provides a multi-tenant authentication and access management method based on multi-factor authentication and the ABAC model. By introducing a multi-factor authentication mechanism and an attribute-based access control model, the security of authentication and the accuracy of access management are improved, thereby enhancing the security, flexibility, and automation in a multi-tenant environment.

[0027] This invention constructs an integrated identity authentication and permission management system based on "layered authentication, precise authorization, and dynamic adaptation." It employs a distributed deployment architecture suitable for different levels, specifically a distributed architecture including a master node and multiple edge nodes. The master node uniformly formulates an ABAC permission policy library (including data classification rules, tenant isolation rules, etc.) and distributes it to each edge node. Edge nodes perform rapid authentication based on a locally cached permission policy library, eliminating the need to send a request back to the master node, thus meeting the low-latency requirements of measurement data processing.

[0028] By establishing a multi-factor authentication mechanism at edge nodes, the limitations of traditional single "username-password" authentication are broken, and a three-level authentication system of "basic factors + enhanced factors + dynamic factors" is constructed. The combination of authentication factors is dynamically adjusted according to the tenant's security level to achieve matching and adaptation between authentication strength and business needs.

[0029] Basic authentication factors: Centered on tenant's unique identifier (e.g., tenant ID) and password, a password encryption and storage mechanism based on the PBKDF2 algorithm is employed. Through multiple hash iterations and salt obfuscation, plaintext password leakage or brute-force attacks are prevented. Let... For the user's plaintext password, The salt value is randomly generated. This represents the number of iterations. Given the length of the derived key, then the derived key... The following formula is used to calculate:

[0030] in, This represents the result calculated using a PRF (pseudo-random function, typically HMAC-SHA256). One data block, The XOR sum iterative calculation here is defined as:

[0031]

[0032]

[0033] in, This means encoding the integer i into a 32-bit (4-byte) bit string in Big-Endian format.

[0034] Biometric Enhancement Factor: Introduces biometric authentication methods such as fingerprint recognition and facial recognition, which tenants can configure and enable independently according to their own business security needs. Employing a model of local feature extraction + cloud-based encrypted comparison, the original biometric data is stored only locally on the tenant's terminal, while the cloud only retains the encrypted feature template, ensuring the privacy and security of biometric information.

[0035] Dynamic Token Enhancement Factor: Offers both hardware and software dynamic tokens. Hardware tokens generate a 6-digit dynamic verification code using a time synchronization algorithm. Software tokens, hosted on a mobile app, support event-triggered (e.g., login request) dynamic code generation. The validity period of the dynamic code is limited to 30 seconds, and each generation is bound to the tenant's current login terminal IP address to prevent cross-terminal abuse. Define a time counter. :

[0036] in, This is the start time, which defaults to 0 and corresponds to January 1, 1972, 00:00:00 UTC. For time step, The current time. A dynamic verification code generated based on a time counter. It can be calculated using the following formula:

[0037] in, For shared keys, The number of digits in the verification code. The Truncate function represents an integer value dynamically truncated from the HMAC hash value. Secure Hash Algorithm 1 is a cryptographic hash function. This represents the modulo operation (remainder), where the modulus is 10 raised to the power of d.

[0038] Based on the set basic authentication factors, biometric enhancement factors, and dynamic token enhancement factors, a dynamic adaptation mechanism for authentication factors is constructed. Specifically, three security level thresholds—high, medium, and low—are preset. For example, tenants with high security levels need to complete three levels of authentication: "basic factors + biometrics + dynamic token," while tenants with low security levels can complete only two levels of authentication: "basic factors + dynamic token." Furthermore, tenant administrators can manually adjust the authentication strength.

[0039] Establish precise permission management rules based on ABAC on the master node, build a permission control model with attributes as the core, and achieve fine-grained permission allocation for tenants and roles within tenants by defining multi-dimensional attributes and attribute association rules. The specific implementation method is as follows: ① Multi-dimensional attribute system definition: Construct a four-dimensional attribute system including tenant attributes, user attributes, resource attributes, and environment attributes. The specific content of each dimension attribute is as follows: Tenant / Organization Attributes: including edge node identifier, function, and region; Resource attributes: Strictly based on data classification standards, including security level (core, important, general), negative list type, and sensitive field identifiers (such as ID card number, mobile phone number). User / role attributes: Role information for the 4A platform, including data administrator, business analyst, and operations personnel; Environment attributes: including access source (master node / edge node), access time, and network type.

[0040] ② Attribute Association Rule Engine Construction: A permission decision rule base is built based on rule engine technology (such as Drools). Rules are defined in the form of "IF-THEN", for example: "IF 'Tenant Business Type = Municipal Power Supply Bureau' AND 'Resource Data Sensitivity = High' AND 'User Role = Tenant Administrator' AND 'Access Environment = Intranet', THEN allows data query and modification operations." The rule base supports tenant administrators in customizing and extending rules according to their own business needs, but all rule changes must be audited and filed.

[0041] ③ Tenant Isolation and Access Boundary Control: By forcibly associating tenant attributes with resource attributes, a one-to-one or one-to-many binding between tenants and resources is achieved, ensuring that tenants can only access resources within their authorized scope. Simultaneously, an "access mask" mechanism is introduced to finely divide the permissions of different roles within a tenant. For example, ordinary employees can only access low-sensitivity resources, while tenant administrators can access all tenant resources but are subject to operation log auditing constraints.

[0042] Because multi-dimensional attribute data contains a large amount of sensitive information, this invention adopts a storage strategy of "categorized storage + encrypted protection." Core attributes are stored in a relational database, while sensitive attributes are stored in an encrypted database. Sensitive attributes are processed using the AES-256 encryption algorithm before storage. Simultaneously, data anonymization technology is used to mask sensitive information in logs and audit reports to ensure attribute data security. Core attributes and sensitive attributes are distinguished based on the data's purpose and the degree of data privacy sensitivity. Sensitive attribute data involves personal privacy or critical data content; leakage would pose a security risk, therefore it needs to be encrypted with AES-256 and stored in an encrypted database. It is defined as data involving user privacy, data that can directly identify a specific natural person, or data that requires strict protection according to law. Core attribute data is the foundational support data for identity verification and permission judgment, and needs to be frequently accessed and quickly read by the rule engine; therefore, it is stored in a relational database to ensure performance. It is defined as structured data used to describe entity characteristics, make logical associations, and support ABAC strategy operations.

[0043] Establish a dynamic permission adjustment mechanism to achieve real-time and automatic permission adjustments. Based on a dual mechanism of event-driven and periodic detection, ensure that permissions can adapt promptly when tenant business changes or security incidents occur. As described below: ① Event-driven permission adjustment: A preset permission adjustment trigger event library is used, including tenant business change events, security events (such as password leakage, abnormal login), and user information change events (such as user job transfer, role change). When an event occurs, the event information is pushed to the permission adjustment engine in real time, and the permission adjustment engine automatically executes the permission adjustment operation according to preset rules.

[0044] The preset rules are defined using an "Event-Condition-Action (ECA)" model. An example of a preset rule is shown below: Circuit breaker rules for security incidents: IF (If an account is detected to have "short-term cross-city login" OR "password entered incorrectly 5 times") THEN (Execute "privilege downgrade" operation, adjust the account's permission set from "core operation rights" to "basic browsing rights", that is, freeze "data export" and "policy configuration" permissions, and only retain "non-sensitive data query" permission).

[0045] Adaptation rules for changes in user information: IF (When a "User Job Change" event occurs AND New Job != "Data Administrator") THEN (Immediately revoke the user's "Modify" and "Delete" permissions for "Core Measurement Data" and trigger the "Re-authenticate" instruction).

[0046] Dynamic blocking rules based on risk scores: IF (the calculated user dynamic risk score > the preset high-risk threshold) THEN (trigger the "block access" operation and send a high-risk alarm log to the audit center).

[0047] ② Periodic detection-type permission adjustment: Perform compliance checks on the permission configurations of all tenants at preset periods, compare the matching degree between the tenant's current business needs, security level and existing permission configurations. If permission redundancy or missing permissions are found, permission adjustment suggestions are automatically generated. After confirmation by the tenant administrator, the adjustment operation is executed, or the adjustment is automatically completed according to the tenant's preset policy.

[0048] ③ Permission Adjustment Log and Retrospective Mechanism: All permission adjustment operations generate detailed logs, recording information such as the triggering event, permission status before and after the adjustment, the operator, and the operation time. The log data uses tamper-proof blockchain storage technology to ensure the integrity and traceability of the logs. Simultaneously, tenant administrators can use the log query function to retrospectively review the permission change history, meeting compliance audit requirements.

[0049] Define tenant Resources The current set of permissions held is The ideal minimum permission set calculated based on the current attributes is: Define the permission deviation index :

[0050] At the same time, dynamic risk scoring is introduced. Used to trigger adjustments:

[0051] in, Normalized scores for historical violations or abnormal behavior; The data sensitivity of the currently accessed resource; Environmental risk factors (such as remote IP address, non-working hours); , , For weighting coefficients. When Greater than the threshold When this occurs, it triggers permission downgrade or blocking.

[0052] The currently held set of permissions represents the tenant. or the resources actually owned by its internal users at the current moment. The set of all operation permissions. This includes permissions for resources. Various operation commands, such as {read, modify, delete, export, policy configuration}. Before adjustments are triggered, the currently held permission set is usually equal to or greater than the permission range required by the user's actual business (i.e., there may be redundant permissions from the past).

[0053] The ideal least privilege set represents the minimum set of permissions required for the current business operation, calculated in real-time based on the ABAC model and multi-dimensional attributes (including the user's current role, access time, network environment, resource sensitivity level, etc.). It is a mathematical expression of the "Least Privilege Principle." The ideal least privilege set contains only a subset of operation instructions allowed under the current specific context.

[0054] The numerator in the expression actually calculates the symmetric difference set, which quantifies the mismatch between "currently held permissions" and "theoretically required permissions." Contains a large number of If a permission does not exist, it indicates redundant permissions, and these permissions should be revoked; when Includes If a permission is not present, it indicates a lack of permissions, and an authorization request suggestion should be triggered.

[0055] Establish an audit and monitoring mechanism to ensure the effectiveness of the authentication and access control system, and build a full-process audit and real-time monitoring mechanism to achieve comprehensive supervision of identity authentication behavior, access control behavior and resource access behavior.

[0056] ① Real-time monitoring: Authentication logs, permission adjustment logs, and resource access logs are collected in real time by integrating log collection tools (such as ELK Stack). Key metrics are displayed on a visual monitoring platform, and alarms are automatically triggered when metrics exceed preset thresholds. Key metrics include: identity authentication anomaly metrics (such as authentication failure rate, number of consecutive erroneous attempts in a short period), number of unauthorized cross-tenant access attempts, frequency of access to highly sensitive resources, real-time dynamic risk score distribution of users, and frequency of dynamic permission adjustment triggers (such as the number of times automatic degradation or circuit breaker occurs).

[0057] ② Full-process audit: The audit scope covers the entire identity authentication process (such as authentication factor verification results and reasons for authentication failure), the entire access control process, and the entire resource access process. The audit report can be generated by tenant, time, event type, and other dimensions, meeting compliance requirements such as Cybersecurity Classified Protection 2.0 and GDPR.

[0058] Example 1 The present invention will be described in detail below through an embodiment: For the management of enterprise-level measurement data of a provincial power company, a distributed deployment architecture of "provincial and municipal levels" is adopted. The provincial master node is responsible for global policy management and distribution, while the municipal edge nodes are responsible for efficient authentication and access control of local data.

[0059] like Figure 2 As shown, the processing flow based on the method of the present invention is as follows: 1. The provincial master node distributes a unified ABAC permission policy library (including data security level classification rules, tenant isolation rules, etc.) to edge nodes of multiple municipal power supply bureaus across the province. When a user of a municipal power supply bureau (tenant) initiates an access request, the edge node performs fast authentication based on the latest policy library cached locally, without having to send it back to the provincial center for each request, thus meeting the low-latency requirements for measurement data processing.

[0060] 2. Multi-factor-based hierarchical identity authentication Suppose a "distribution network maintenance personnel" from the local power supply bureau needs to view "transformer overload monitoring data" within their jurisdiction. They need to initiate a request and complete identity authentication, as follows: The user is a high-security tenant and requests access to core data, automatically triggering a three-level authentication process. The user must complete the following steps in sequence: ① Static password verification; ② Fingerprint collection for biometric comparison; ③ Input of a dynamic verification code (TOTP) generated by a hardware token. Only after all three verifications are passed can the user be authenticated and obtain an identity credential (Token).

[0061] 3. Precise authorization and resource isolation based on the ABAC model After a user logs in, they initiate a specific data query request. For this request, a real-time decision is made based on the four-dimensional attributes. Attribute matching: Read the current attribute information - the user role is "Operation and Maintenance Personnel", the tenant identifier is "City A Bureau", the current time is "Workday 09:00", the network environment is "Internal Private Network", and the requested data is the core data "Transformer Overload Monitoring Data".

[0062] Rule determination: Matching rule: "IF 'tenant=A municipal bureau' AND 'role=operation and maintenance personnel' AND 'environment=internal network', THEN allows querying heavy overload data under the name of A municipal bureau".

[0063] If the operations and maintenance personnel attempt to modify or query data belonging to "City B Bureau", and find that the "Owning Tenant ID" in the resource attribute does not match the "Tenant ID" in the user attribute during attribute matching, access will be immediately denied, ensuring strict isolation of cross-city data.

[0064] 4. Event-driven dynamic permission adjustment If the security center detects that the operations and maintenance personnel's account has made a cross-city login within 5 minutes (triggering an "abnormal login" security event), the permission level of the operations and maintenance personnel's account will be adjusted according to the dynamic permission adjustment mechanism.

[0065] Specifically, based on the preset circuit breaker policy, the account's permission level was automatically and temporarily downgraded from "core operation rights" to "basic browsing rights". After the permission adjustment, the account immediately lost the permissions for "data export" and "policy configuration", retaining only the permission to view non-sensitive data, thereby minimizing the risk of data leakage without completely interrupting business operations.

[0066] 5. Full-process audit All of the above authentication processes, authentication decision results, unauthorized access attempts, and automatic permission downgrade operations are recorded in the audit log in real time and periodically synchronized to the blockchain storage system of the provincial master node to meet the requirements of the power industry graded protection (graded protection 2.0) and data security compliance audit.

[0067] Example 2 This embodiment is based on the "provincial and local level" distributed deployment architecture established in Embodiment 1, and demonstrates the operation process of tenant administrators updating and distributing global security policies in the provincial master node environment.

[0068] Suppose a "data security administrator" at the provincial master node needs to update the province's "sensitive data negative list," define the newly added "new energy user energy storage configuration data" as core sensitive data, and distribute this policy to edge nodes in various cities and prefectures throughout the province.

[0069] Because this operation involves a province-wide policy change and is classified as the highest-risk operation, a three-level authentication process is forcibly triggered: the administrator must sequentially complete static password verification based on the PBKDF2 algorithm, facial feature recognition using a combination of local extraction and cloud comparison, and input a valid TOTP dynamic verification code generated by the software token. After passing all three verifications, the administrator is granted policy configuration permissions. Subsequently, the administrator initiates a policy update request. The master node's permission engine, based on the ABAC model, collects attributes such as the administrator's "Provincial Data Administrator" role, "Provincial Data Center" tenant ID, and "Internal Network Management Segment" IP address, matches them with the preset rule of "Allowing modification of the global policy library," and verifies through tenant isolation. After successful authentication, the administrator completes the policy update and initiates a province-wide collaborative synchronization mechanism, automatically distributing the encrypted new ABAC policy library to edge nodes in all cities and prefectures across the province to ensure the new rules take effect immediately. Simultaneously, the master node records the complete trajectory of this operation and a snapshot of the policy change, and synchronizes the audit log to the blockchain evidence storage system for solidification to meet compliance review requirements.

[0070] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A multi-tenant authentication and access control method based on multi-factor authentication and ABAC model, characterized in that, It adopts a distributed architecture that includes a master node and multiple edge nodes; Establish ABAC-based permission management rules on the master node, define multi-dimensional attributes, and build a permission decision rule library to achieve fine-grained permission allocation for tenants and roles within tenants; distribute the established permission management rules to each edge node for permission verification when edge nodes make business requests. Establish a multi-factor authentication mechanism at each edge node, set up an authentication system that combines multiple factors, and dynamically adjust the combination of authentication factors according to the tenant's security level; In addition, a dynamic permission adjustment mechanism and an audit and monitoring mechanism are set up; through the dynamic permission adjustment mechanism, tenant permissions are dynamically adjusted when tenant business changes or security incidents occur; through the audit and monitoring mechanism, the business operations of the master node and each edge node are recorded and monitored.

2. The method according to claim 1, characterized in that, The permission management rules based on ABAC include: Define a multi-dimensional attribute system, setting tenant attributes, user attributes, resource attributes, and environment attributes; among them, tenant attributes include edge node identifier, function, and region; user attributes include user role information; resource attributes include the security level of resource data; and environment attributes include access source, access time, and network type. A permission decision rule base is constructed using rule engine technology. The rules are defined in the form of "IF-THEN", where IF is used for attribute matching and THEN is used to issue a notification that the operation can be performed after the attribute matching is successful. Set up a tenant isolation mechanism to associate tenant attributes with resource attributes, enabling one-to-one or one-to-many binding between tenants and resources, so that tenants can only access resources within their authorized scope; at the same time, introduce a permission mask mechanism to divide the permissions of different users within a tenant.

3. The method according to claim 2, characterized in that, A storage strategy combining categorized storage and encryption protection is adopted to store multi-dimensional attribute data. Core attributes are stored in a relational database, while sensitive attributes are stored in an encrypted database. Sensitive attributes are processed using the AES-256 encryption algorithm before storage.

4. The method according to claim 1, characterized in that, Establishing a multi-factor authentication mechanism includes setting up an authentication system that combines multiple factors, including basic authentication factors, biometric enhancement factors, and dynamic token enhancement factors; The basic authentication factors include the tenant's unique identifier and password. The tenant's password is encrypted using the PBKDF2 algorithm and then stored. The biometric enhancement factor is the tenant's biometrics. The biometric enhancement factor is verified by a combination of local feature extraction and cloud-based encrypted comparison. The original biometric data is stored only locally on the tenant's terminal, while only the encrypted feature template is stored in the cloud. The dynamic token enhancement factor is either a hardware dynamic token or a software token; a hardware dynamic token is a dynamic verification code generated through a time synchronization algorithm; a software token is an event-triggered dynamic code, and each generated dynamic code is bound to the tenant's current login terminal IP to prevent the dynamic code from being used across terminals. Based on the three set factors, the security level of the tenant is preset, and different combinations of authentication factors are selected according to the tenant's security level.

5. The method according to claim 4, characterized in that, The method for generating the hardware dynamic token includes defining a time counter. : In the formula, The start time, For time step, The current time; a dynamic verification code generated based on a time counter. Represented as: In the formula, For shared keys, The number of digits for the verification code; the Truncate function indicates from HMAC The integer value dynamically extracted from the hash value; This represents Secure Hash Algorithm 1. This represents the modulo operation, where the modulus is 10 raised to the power of d.

6. The method according to claim 1, characterized in that, The dynamic permission adjustment mechanism includes event-driven permission adjustment and periodic detection-based permission adjustment. Event-driven permission adjustment includes a preset permission adjustment trigger event library. When the corresponding event in the permission adjustment trigger event library occurs, the permission adjustment operation is executed according to preset rules. Periodic detection-based permission adjustments include performing compliance checks on the permission configurations of all tenants at preset intervals, comparing the matching degree between the tenant's current business needs, security level and existing permission configurations, and automatically generating permission adjustment suggestions if permission redundancy or missing permissions are found. After confirmation by the tenant administrator, the adjustment operation is executed, or the adjustment is automatically completed according to the tenant's preset policy.

7. The method according to claim 1, characterized in that, The auditing and monitoring mechanism includes collecting authentication logs, permission adjustment logs, and resource access logs in real time through access log collection tools, displaying key indicators through a visual monitoring platform, and automatically triggering alarms when the indicators exceed preset thresholds.

Images