Multi-tenant-based centralized authentication and authorization system, method, equipment and medium

Abstract

The invention provides a multi-tenant-based centralized authentication and authorization method, system, device and medium, and belongs to the technical field of security and identity management, and the system comprises a unified portal layer, an authentication layer, an authorization layer, a strategy center and an audit monitoring layer. The unified portal layer receives a user request, identifies and injects a tenant identifier, and executes WAF rule verification, JWT signature verification and Token blacklist check; the authentication layer performs user or client credential verification on different accessed identity sources, generates and issues a JWT, and monitors the life cycle of a token; the authorization layer extracts an authority statement in the JWT and a locally cached strategy snapshot; the strategy center provides centralized storage, version management and visual editing of multi-tenant strategies; through cooperative work of each layer, accurate identification, unified authentication, centralized strategy management and comprehensive audit monitoring of tenants are realized. And the security, the expandability and the management efficiency of the system are effectively improved.

Description

Technical Field

[0001] This invention belongs to the field of security and identity management technology, specifically relating to a multi-tenant centralized authentication and authorization system, method, device, and medium. Background Technology

[0002] Against the backdrop of accelerated digital transformation, enterprises are increasingly demanding efficient, secure, and flexible information systems. Traditional monolithic application architectures are gradually being replaced by microservice architectures, which not only improves system scalability and flexibility but also places higher demands on unified access control and security management. With the development of emerging technologies such as cloud computing, big data, and the Internet of Things (IoT), cross-platform and cross-organizational resource sharing and service calls are becoming increasingly common, further intensifying the need for integration layers, authentication and authorization mechanisms, policy management, and audit and monitoring capabilities.

[0003] In related technologies, tenant identification in multi-tenant environments is difficult to achieve and access is complex. Reliance on fixed domain names makes it difficult to adapt to diverse business access scenarios. Enterprises often have multiple identity sources internally, such as LDAP and Enterprise Active Directory, and externally, they need to connect to third-party OAuth platforms. The different identity source protocols and interfaces vary significantly, making integration difficult.

[0004] The RBAC model cannot meet the needs of dynamic access control, such as time-based and location-based access control, while the pure ABAC model has low decision-making efficiency. Multi-tenant policies involve distributed storage, making unified management difficult; the lack of a canary release mechanism when updating policies can easily affect online services. Summary of the Invention

[0005] This invention provides a multi-tenant centralized authentication and authorization system that can provide efficient, controllable and reliable comprehensive protection for unified authentication and authorization under multi-tenant cloud platforms and microservice architectures.

[0006] The system includes: a unified portal layer, an authentication layer, an authorization layer, a policy center, and an audit and monitoring layer; The unified portal layer receives user requests, identifies and injects tenant identifiers, performs WAF rule verification, JWT signature verification and Token blacklist checks, and intercepts illegal traffic and maintains session state. The authentication layer verifies user or client credentials from different identity sources, generates and issues JWTs, and monitors the token lifecycle. The authorization layer extracts the permission declarations in the JWT and the policy snapshots cached locally, and combines the RBAC and ABAC hybrid decision model to determine permissions, returning a Permit or Deny result; The policy center provides centralized storage, version management, and visual editing of multi-tenant policies, and broadcasts policy updates to all authorized nodes; The audit and monitoring layer logs and monitors the behavior of key audit elements during the strategy execution process, and predicts and triggers alarms for abnormal behavior.

[0007] It should be further explained that after receiving a user request, the unified portal layer parses the tenant identification information in sequence according to the preset priority, and checks the tenant ID by checking the custom HTTP header, the tenant prefix in the URL path, the domain name suffix, etc. If all of them fail, an error page is returned and an alarm is triggered. WAF rule verification and JWT signature verification are performed simultaneously. WAF intercepts attack requests by pattern matching based on predefined feature strings. JWT verification uses private keys managed by HSM (Hardware Security Module) or KMS (Key Management Service) to verify signatures and check token validity and issuer. Perform a token blacklist linkage check, maintain a blacklist set through a distributed cache, and verify the jti field of the JWT to determine whether to reject the request; Perform session state initialization and consistency maintenance, generate SessionID and bind it with JWT to store in distributed cache, write Cookie to user browser, and maintain session state using Cache-Aside mode.

[0008] It should be further explained that after the authentication layer receives the login request forwarded by the unified portal based on the authentication service, it calls the corresponding adapter module to complete the standardized extraction of credentials according to the tenant's pre-configured information. After the basic credentials verification is successful, the authentication service decides whether to trigger factor verification based on tenant policies and user behavior analysis. During verification, the authentication service and the MFA service interact through a TLS encrypted channel to verify the validity of the factors and record the MFA verification results to the audit log. The authentication layer generates a secure signature within the JWT personalized claim; After successful verification, the authentication service generates a JWT payload containing tenant ID, user ID, a predefined role mapping table from the tenant, permission declaration, device fingerprint, and MFA verification status. The authentication service maintains a distributed cache storage of token blacklists and supports immediate revocation operations.

[0009] It should be further explained that after the authorization layer receives the API call request, it extracts a subset of differentiated policies that are strongly related to the request from the locally cached policy snapshot based on the tenant identifier and resource type in the request. Policy snapshots are stored in isolation by tenant by the policy center. After retrieval, the authorization layer verifies the consistency between the version number of the policy snapshot and the latest version in the policy center, and checks the expiration time of the snapshot. After verifying the validity of the policy snapshot, the authorization layer selects a decision mode based on the sensitivity level of the request. For low-risk requests, the RBAC model is used first to quickly match user roles with predefined permissions. For high-risk requests, the ABAC model is triggered to evaluate conditions by combining user attributes, resource attributes, and environmental context. If the results of the two models differ, the ABAC result shall prevail. The authorization layer maintains a long-lived heartbeat connection with the policy center and periodically retrieves the latest version number of the policy center.

[0010] It should be further noted that the policy center creates an independent policy storage space for each tenant, which is linked to each tenant's space through soft links or references. Tenant-specific policies support custom extended fields. The strategy center uses a Git-like version control model, where each strategy change generates a new version and records the change log. The policy center supports policy branch management, allowing tenants to select a specific branch to synchronize policies; during version merging, the system detects differences and prompts the administrator to resolve them manually. When a policy is updated, the policy center generates an incremental difference packet and broadcasts it to each authorized node via the message bus. Authorized nodes only pull the difference packet related to their own tenants and verify the signature of the difference packet to ensure its integrity.

[0011] It should be further explained that after receiving the logs, the audit and monitoring layer stores the logs in multi-tenant isolation based on the global transaction ID and tenant identifier injected from the unified portal layer. Each tenant's logs are stored in an independent Elasticsearch index, and cross-tenant call relationships are recorded in the log metadata; a unique log tracing chain ID is generated for each tenant, linking the logs of all related requests for that tenant; The audit and monitoring layer learns normal behavior patterns based on the LSTM time series model and historical log data. When behavior that deviates from the baseline is detected, the alarm policy is adjusted and the operation and maintenance personnel are notified via email / SMS.

[0012] It should be further noted that the authorization layer defines the policy difference condition C={(P i ,P j Strategy P i With strategy P j If there are mutually exclusive rules, monitor policy difference conditions. When a difference is detected, traverse the policy dependency graph using the DFS edge detection algorithm to identify the difference condition pairs and trigger priority adjustment. In the hybrid RBAC / ABAC decision model, a context-based policy fusion logic is added to map user roles, resource attributes, time, geographical location, and device type into decision vectors, and calculate the final authorization result through a tenant-defined policy weight function. The formula for calculating the decision vector is: S = w1⋅R + w2⋅A + w3⋅E Where S is the overall score, R is the role permission weight, A is the resource attribute matching degree, E is the environmental context adaptability, and w1, w2, w3 are the tenant-defined dimension weight coefficients. When the Strategy Center pushes an update, it generates a difference package D={new strategy, modified strategy, deleted strategy}. The licensed service resolves the patch and updates the local snapshot as follows: For each new strategy p∈D, add it and insert it into the corresponding position in the snapshot; Modify the strategy p∈D to replace the old version of the attribute value; For deletion policy p∈D, remove from the snapshot.

[0013] This application also provides a multi-tenant centralized authentication and authorization method, the method including: Step 201: The user terminal sends a service access request to the unified portal layer. After receiving the request, the unified portal layer performs a tenant context injection operation and determines the tenant subject to which the current request belongs based on the tenant identification information carried in the request. Then, it performs route parsing processing, matching the corresponding service processing path according to the service type and target resource address of the request to form the service request information after preliminary processing. Step 202: After the business request information is processed by the unified portal layer, the resource integration and application integration processing flow is initiated; It calls upon the underlying infrastructure resource pool to schedule and integrate computing, storage, and network resources; it standardizes the conversion of heterogeneous interfaces of different business systems, and uses the adapter pattern to achieve unified conversion and protocol adaptation of cross-system data formats, forming business processing requests that conform to subsequent processing specifications. Step 203: The authentication layer compares and verifies the user credentials in the business processing request with the pre-stored authentication information to generate a user identity authentication result; based on the authentication result and combined with the permission policy data issued by the policy center, it performs permission verification on the user request and generates authorization information. Step 204: Based on the authorization information, the policy center obtains policy snapshot data from the cache layer, checks the Token blacklist, and verifies whether the identity token carried by the authorization information exists in the blacklist of invalid, stolen, or illegally used tokens; combining the rule matching results of the policy snapshot with the Token blacklist verification results, a business execution policy instruction containing access control instructions is generated. Step 205: Allocate resources and schedule processes for business requests according to business execution strategy instructions; Specifically, based on the computing resource requirements allocated in the business execution strategy instructions, the corresponding data interaction channels are enabled according to the interface call permissions; at the same time, key audit elements in the strategy execution process are transmitted to the audit monitoring layer in real time. Step 206: The audit and monitoring layer logs and monitors the behavior of key audit elements during the strategy execution process.

[0014] According to another embodiment of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the multi-tenant centralized authentication and authorization system.

[0015] According to yet another embodiment of this application, a storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the multi-tenant centralized authentication and authorization system.

[0016] As can be seen from the above technical solutions, the present invention has the following advantages: This application relates to a multi-tenant centralized authentication and authorization system that improves the accuracy and flexibility of tenant identity recognition. It integrates WAF rule verification, JWT signature verification, and token blacklist checks to form a multi-layered security protection system, effectively intercepting attacks such as SQL injection and XSS, and ensuring system boundary security. Based on the OAuth2.0 / OpenIDConnect standard, it is compatible with multiple identity sources and utilizes HSM or cloud KMS to manage keys, ensuring the compliance of JWT signatures and encryption / decryption. Short-lifecycle tokens and a blacklist mechanism enable immediate token revocation, reducing the risk of token leakage and improving the stability and response speed of the authentication service. Local policy caching and differentiated snapshot acquisition achieve millisecond-level response times for permission decisions. A hybrid RBAC and ABAC decision model balances static role permissions with dynamic attribute control, meeting the flexible permission management needs of complex business scenarios.

[0017] The policy center facilitates unified maintenance and traceability of multi-tenant policies for administrators; event-driven differential update push reduces network and storage pressure; canary releases, one-click rollback, and post-rollback verification and cleanup mechanisms ensure policy update security and avoid impacting online services. Full-link log tracing based on OpenTelemetry enables complete reconstruction of cross-service call chains, facilitating problem localization; structured log aggregation and anonymized sensitive data storage meet compliance audit requirements; customizable alarm rules and multi-channel notifications ensure rapid response to security incidents. Through the collaborative design of these modules, the system significantly improves flexibility, efficiency, and stability while ensuring multi-tenant security isolation, and meets the authentication and authorization needs of complex enterprise business scenarios. Attached Figure Description

[0018] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of a multi-tenant centralized authentication and authorization system. Figure 2 This is a flowchart of an embodiment of a multi-tenant centralized authentication and authorization method. Figure 3 This is a schematic diagram of an electronic device. Detailed Implementation

[0020] This application involves a multi-tenant centralized authentication and authorization system based on cloud-native microservices. It is distributed across five logical components: a unified portal layer, an authentication layer, an authorization layer, a policy center, and an audit and monitoring layer. These are supplemented by infrastructure such as a caching layer, a message bus, and service registration and discovery, supporting the integration of multiple resources and applications and ensuring seamless connection and access control between different systems and services. All user requests are first received through the unified portal, which is responsible for tenant context identification, preliminary security verification, and routing, transparently forwarding requests to the authentication or authorization service. The authentication layer uses the OAuth2.0 / OpenIDConnect protocol standard to interface with multiple identity sources to complete identity verification and token issuance. The authorization layer, based on locally cached policy snapshots, makes fast and fine-grained access decisions for API calls or inter-service calls. The policy center provides centralized policy management and visual editing, and drives canary or full deployments via the message bus. The audit and monitoring layer continuously collects end-to-end logs and tracing data, monitors anomalies in real time, and supports alerts and compliance audits. The caching layer is mainly used to store token blacklists, policy snapshots, and session information. The message bus is used to carry out policy distribution and audit event push. Service registration and discovery and the service mesh ensure the high availability, elastic scaling, and tracing capabilities of each microservice.

[0021] This invention implements a decentralized authorization decision architecture. Authorization nodes can independently complete permission verification based on local policy cache and user JWT declarations, without having to query the policy center in the business call path, thus improving the availability and response performance of the system.

[0022] The following describes in detail the multi-tenant centralized authentication and authorization system involved in this application. Specific details, such as particular system architectures and technologies, are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details.

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] Please see Figure 1 The diagram shown is a schematic of a multi-tenant centralized authentication and authorization system in a specific embodiment. The system includes: a unified portal layer, an authentication layer, an authorization layer, a policy center, and an audit and monitoring layer.

[0025] The unified portal layer receives user requests, identifies and injects tenant identifiers, performs WAF rule verification, JWT signature verification and token blacklist checks, and intercepts illegal traffic and maintains session state.

[0026] In some embodiments, the unified portal layer serves as the sole entry point to the system, handling all incoming user requests. It first identifies and injects tenant identifiers, such as through domain suffixes, URL prefixes, or custom HTTP headers, and injects identifiers like X-Tenant-ID into the request. Simultaneously, it performs WAF rule validation to check for common attack patterns, such as SQL injection and XSS. It also performs signature validation on JWTs to verify their integrity and validity, and checks if the token is on a blacklist, blocking unauthorized traffic. Furthermore, it maintains session state and manages user session information.

[0027] For the unified portal layer, the tenant identifier injection process is based on parsing the domain name, URL parameters, or custom HTTP headers of the request, and accurately identifies tenants through multi-dimensional matching.

[0028] WAF rule verification targets attacks such as SQL injection and XSS. It works in conjunction with the security operations center to differentiate between tenants and customize protection strategies, such as enabling stricter XSS filtering for high-security tenants.

[0029] JWT signature verification supports multiple algorithms such as RSA and ECDSA. It associates the tenant key during verification. Blacklist checking achieves millisecond-level interception through distributed caching. Session state maintenance supports three transmission modes: Cookie, Header, and Token, and is compatible with different terminals.

[0030] The unified portal layer, serving as the system's entry point, centrally manages and controls all incoming requests, providing unified security and session management. By identifying and injecting tenant identifiers, it ensures that subsequent services accurately identify and process requests from different tenants. WAF rule verification and JWT signature verification effectively block illegal traffic, protecting system security. Session management enhances user experience, facilitating the tracking and management of user requests.

[0031] The authentication layer verifies user or client credentials from different identity sources, generates and issues JWTs, and monitors the token lifecycle.

[0032] Specifically, the authentication layer is based on the OAuth 2.0 / OpenIDConnect standard, handling user or client credential verification from different identity sources. It can interface with various identity sources such as LDAP, enterprise Active Directory, and third-party OAuth for verification. After successful user or client credential verification, a JWT containing tenant ID, user ID, role, and permission declarations is generated and issued. Simultaneously, the token lifecycle is managed, including a short lifecycle design, a blacklist mechanism, and credential rotation.

[0033] The authentication layer in this embodiment supports tenant-level custom claim extensions, such as attaching security level labels to high-privilege users, and ensuring key security by hosting the signing key through HSM or cloud KMS. During the token lifecycle, short-cycle tokens adjust the refresh window based on user behavior frequency, the blacklist is synchronized to all authentication nodes through a write-to-broadcast mechanism, and credential rotation supports configuration of rotation cycle by tenant.

[0034] The authentication layer provides a unified authentication service that supports multiple identity sources, allowing users to authenticate using different identities. By generating and managing JWTs, stateless authentication is achieved, improving system scalability and performance. Short-cycle design and a blacklist mechanism enable the timely revocation of invalid or leaked tokens, enhancing system security.

[0035] The authorization layer extracts the permission declarations from the JWT and the policy snapshots cached locally, and uses a hybrid decision model of RBAC and ABAC to determine permissions, returning a Permit or Deny result.

[0036] In this embodiment, the authorization layer receives business API call requests and extracts permission claims from the JWT. Simultaneously, it retrieves policy information from locally cached policy snapshots, which are differentiated snapshots from the policy center. The authorization layer uses a hybrid RBAC and ABAC decision model for permission determination. If there is a delay in policy synchronization, the authorization layer will handle degradation and retry mechanisms to ensure the accuracy and timeliness of permission determination.

[0037] It should be noted that RBAC stands for Role-Based Access Control, while ABAC stands for Attribute-Based Access Control.

[0038] When a business API call request reaches the authorization layer, the system first extracts the JWT from the request and retrieves the permission declaration within it. Then, it reads the policy snapshot from the local cache and performs permission checks using RBAC and ABAC models. If the check succeeds, a Permit result is returned; otherwise, a Deny result is returned. In the event of policy synchronization delay, the authorization layer will use a degradation mechanism, making a judgment based on the last successfully synchronized policy and attempting to resynchronize the policy.

[0039] As can be seen, the authorization layer provides access control, ensuring that only authorized users or clients can access specific resources and functions. Combining RBAC and ABAC models, it can flexibly meet the permission requirements of different business scenarios. Locally cached policy snapshots improve the efficiency of permission judgment and reduce dependence on the policy center. The degradation and retry mechanism ensures that the system can still perform permission judgment normally even with policy synchronization delays, improving the system's reliability and stability.

[0040] The policy center provides centralized storage, version management, and visual editing of multi-tenant policies, and broadcasts policy updates to all authorized nodes.

[0041] The policy center in this embodiment is used for centralized storage, version management, and visual editing of multi-tenant policies. It provides a user-friendly interface for administrators to configure and manage policies. The policy center broadcasts policy updates to all authorized nodes via an event-driven approach, supporting canary releases, one-click rollback, and consistency checks and cleanup after rollback.

[0042] In this embodiment, administrators edit and configure policies through a visual interface in the policy center. The policy center manages policy versions, recording historical versions of each change. When a policy is updated, the policy center broadcasts the update to all authorized nodes via an event-driven approach. In canary release mode, the new policy is first applied to a subset of nodes, verified, and then rolled out nationwide. If problems are found, a one-click rollback to the previous version is possible, followed by consistency checks and cleanup to ensure policy correctness and system stability.

[0043] The audit and monitoring layer logs and monitors the behavior of key audit elements during the strategy execution process, and predicts and triggers alarms for abnormal behavior.

[0044] This embodiment uses OpenTelemetryAgent to collect logs non-intrusively, linking them to the portal, authentication, authorization, and policy center, covering the complete path from the user terminal to the audit storage. It employs per-tenant configuration of sensitive fields, supporting multiple modes of de-identification: during collection, before storage, and during querying. Log storage is based on Elasticsearch's hot and cold tiered system. The audit and monitoring layer features end-to-end traceability, allowing any security incident or performance issue to be pinpointed to the specific tenant, request, and policy. Data masking complies with GDPR and information security compliance requirements, preventing the leakage of sensitive data.

[0045] In one embodiment of the present invention, based on a unified portal layer, the following will provide an embodiment of a unified portal layer and describe its specific implementation in a non-limiting manner.

[0046] After receiving a user request, the unified portal layer parses the tenant identification information according to a preset priority: First, it checks whether there is a valid value in the custom HTTP header; if not, it extracts the tenant prefix in the URL path for matching; if it still cannot identify, it determines the tenant ID by resolving the domain name suffix; if all fail, it returns a 'tenant identifier missing' error page and triggers an operation and maintenance alarm to ensure that the tenant's identity is traceable.

[0047] After tenant identification is completed, WAF rule verification and JWT signature verification are performed synchronously. WAF rule verification performs pattern matching on the request content based on predefined SQL injection feature strings, XSS script tags, and CSRF exception Referer. If an attack feature is matched, it is immediately intercepted and the attack log is recorded. JWT signature verification uses the private key managed by HSM (Hardware Security Module) or KMS (Key Management Service) to verify the token signature, confirming that the token was issued by a legitimate authentication service, and checking whether the token validity period and issuer comply with the preset policy.

[0048] When performing token blacklist-linked checks, a distributed cache can be used to maintain a real-time updated token blacklist set. During verification, the jti field of the JWT is extracted, and the cache is checked to see if the identifier exists. If it exists, the request is rejected and a 403 status code is returned; otherwise, the subsequent process continues. A short expiration time is set for the blacklist cache to ensure that revocation commands take effect quickly, while reducing cache storage pressure.

[0049] The unified portal layer performs session state initialization and consistency maintenance by generating a globally unique SessionID and binding it to a JWT after successful verification. The SessionID, JWT content, user roles, and permission declarations are then stored in a distributed cache with a reasonable expiration time. Simultaneously, a Cookie with HttpOnly and Secure attributes is written to the user's browser to store the SessionID, ensuring that subsequent requests automatically carry it. Session state maintenance employs a Cache-Aside model: when reading a session, it prioritizes retrieving it from the cache; if the cache is invalid, the JWT is re-verified and the session is rebuilt. When writing to a session, the cache and Cookie are updated synchronously to ensure session consistency across multiple devices.

[0050] In this embodiment, the unified portal layer serves as the system's unified entry point. Through multi-tenant identification, multi-layered security protection, and session management, it ensures legitimate user requests enter the system while intercepting illegal traffic and maintaining user session state. To address the diversity of tenant access methods in a multi-tenant environment, a compatibility identification strategy is designed. By parsing tenant identifiers in requests according to priority, it ensures that tenants with different access methods can be accurately identified, avoiding access failures due to the absence of a single identifier. A dual protection mechanism combining WAF and JWT is implemented. WAF performs pattern matching on request content based on known attack patterns to quickly block common attacks; JWT verification ensures the token's legitimate origin and expiration through signature verification, validity checks, and issuer verification, preventing the abuse of forged or tampered tokens. These two layers of protection complement each other, covering attack signature detection and identity verification, enhancing system boundary security.

[0051] The system maintains a token blacklist in real time through a distributed cache, supporting immediate revocation. When a user logs out or an administrator manually revokes a token, the system writes the token's unique identifier into the cache. Subsequent verification requests quickly query the cache to determine the token's status. The cache is configured with a reasonable expiration time, balancing revocation timeliness with storage efficiency and preventing invalid tokens from occupying resources for extended periods.

[0052] In one embodiment of the present invention, based on an authentication layer, the following will provide an embodiment of an authentication layer and describe its specific implementation in a non-limiting manner.

[0053] S1021: After receiving the login request forwarded by the unified portal, the authentication service calls the corresponding adapter module to complete the standardized extraction of credentials based on the tenant's pre-configured credentials, such as LDAP, enterprise AD, or third-party OAuth.

[0054] For example, LDAP identity sources are verified using user DN and password, enterprise AD is verified using domain account and NTLM hash, and third-party OAuth is verified using code or access_token. The adapter uniformly converts credentials of different formats into internal standard credential objects to ensure consistency in subsequent verification processes. Credentials include LDAP DN, AD SID, and OAuth code. Internal standard credential objects can contain user identifier, credential value, and verification method.

[0055] S1022: After the basic credential verification passes, the authentication service decides whether to trigger second-factor authentication based on tenant policies and user behavior analysis. It supports multiple methods, including TOTP, SMS / email verification codes, and YubiKey's U2F protocol verification. During verification, the authentication service interacts with the MFA (Multi-Factor Authentication Service) via a TLS encrypted channel to verify the validity of the second factor and records the MFA verification result to the audit log.

[0056] Tenant policies can involve mandatory measures for financial industry tenants, or triggering an MFA (Mean Factor Activation) for first-time login users, etc. Verifying the validity of the second factor can involve matching the TOTP (Total Transaction Processing) code with the expected value of the current time window, or performing a one-time verification of the SMS verification code.

[0057] S1023: JWT Personalized Claim Generates Secure Signature; After successful verification, the authentication service generates a JWT payload containing tenant ID, user ID, a predefined role mapping table from the tenant, permission claim, device fingerprint, and MFA verification status. The signature portion uses a private key protected by HSM (Hardware Security Module) or KMS (Key Management Service) to digitally sign the payload, ensuring the integrity and trustworthiness of the token's origin; it also sets a short lifespan and specifies the expiration time through the exp field to prevent long-term valid tokens from being hijacked and abused.

[0058] S1024: The authentication service maintains a blacklist of tokens stored in a distributed cache, and supports immediate revocation operations. For example, when a user actively cancels their account, the jti field of the JWT is added to the blacklist.

[0059] The authentication layer also involves a credential rotation mechanism. Specifically, when a client credential leak is detected or a tenant policy change is made, a new client_secret is automatically generated and the client is notified to update it through a secure channel, and the old credential becomes invalid immediately. A short-cycle token renewal policy is also included. If a user is in an active session, the validity period of the JWT can be extended by refreshing the token. The refresh token is stored separately in the database and a stricter rotation policy is set to ensure the security of long-term sessions.

[0060] As can be seen, the authentication layer provides a unified and secure identity authentication service for multi-tenant environments through multi-identity source adaptation, MFA verification, security token generation, and lifecycle management, ensuring that legitimate users access resources with the least privilege.

[0061] When MFA needs to be triggered, the authentication service sends an MFA verification request to the user. After the user completes the verification, the authentication service calls the MFA service to verify the validity of the second factor. The MFA verification result and the underlying credential verification result together serve as the basis for token issuance, ensuring that even if the underlying credentials are leaked, attackers cannot bypass the MFA to obtain the token.

[0062] To balance security and user experience, the authentication service employs a short-cycle and refresh token strategy to manage token lifecycles. Refresh tokens are stored separately in the database with a stricter rotation policy. A new refresh token is generated after each use, invalidating the old one and preventing long-term misuse. Furthermore, the authentication service maintains a Redis blacklist storing revoked tokens (jti). When a user logs out or an administrator manually revokes a jti, it is added to the blacklist. Subsequent JWT verification requests will check the blacklist; if the jti is found, the request is rejected, ensuring immediate token invalidation.

[0063] As can be seen, the authentication layer, based on the OAuth2.0 / OpenIDConnect standard, provides unified identity verification and token services for various clients in a multi-tenant environment. Its main responsibilities include accessing different identity sources (LDAP, enterprise AD, third-party OAuth); after verifying user or client credentials, it generates and issues a JWT containing tenant ID, user ID, role and permission declarations.

[0064] The token manager, in conjunction with HSM or cloud KMS, manages keys to ensure compliance with signing and encryption / decryption processes. A short lifespan design and blacklist mechanism enable immediate revocation. Credential management allows each tenant to independently maintain their client_id / client_secret, with automatic rotation and expiration notifications via SDK interfaces. In high-concurrency scenarios, the authentication service employs asynchronous non-blocking I / O and rate limiting strategies, along with distributed caching to reduce pressure on downstream identity sources, ensuring issuance efficiency and system stability. The system supports registering new tenants and automatically initializing policy templates and default configurations. Upon tenant deregistration, configuration reclamation, policy archiving, and data isolation verification are completed to ensure environment cleanup and secure exit.

[0065] In one embodiment of the present invention, based on an authorization layer, the following will provide an embodiment of an authorization layer and describe its specific implementation in a non-limiting manner.

[0066] S1031: After receiving an API call request, the authorization layer extracts a subset of differentiated policies strongly related to the request from the locally cached policy snapshot (stored by the policy center in tenant isolation, including the RBAC role and permission table, ABAC attribute rule set, and dynamic effective timestamp) based on the tenant identifier and resource type. After extraction, it verifies the consistency between the policy snapshot version number and the latest version in the policy center, and checks the expiration time (based on the policy center push timestamp + cache TTL) to ensure that the latest effective policy is used.

[0067] Policy snapshots are stored in isolation by tenant by the policy center and include RBAC role and permission tables, ABAC attribute rule sets, and effective timestamps. After extraction, the authorization layer verifies the consistency between the policy snapshot version number and the latest version in the policy center. This can be done through version vector or hash value verification, and the snapshot expiration time is checked. The expiration time is based on the policy center's push timestamp + cache TTL to ensure that the latest and valid subset of policies is used.

[0068] S1032: After verifying the validity of the policy snapshot, the authorization layer selects a decision mode based on the sensitivity level of the request. For low-risk requests, the RBAC model is used first to quickly match user roles with predefined permissions; for high-risk requests, such as user information modification, the ABAC model is triggered, and conditional evaluation is performed based on user attributes, resource attributes, and environmental context; if the results of the two models differ, such as RBAC allowing but ABAC rejecting, the ABAC result prevails to ensure strict control over high-risk operations.

[0069] S1033: The authorization layer maintains a long-connection heartbeat with the policy center and periodically obtains the latest version number of the policy center; if the local cache version number is inconsistent with the central version number and exceeds the preset synchronization threshold, it is determined to be a policy synchronization delay.

[0070] The system handles delays in stages: For delays of 5-15 minutes, the authorization layer sends an incremental synchronization request to the policy center, retrieving only the changed policy fragments and updating the cache; for delays of 15-30 minutes, a read-only mode is triggered, allowing only decisions based on the old policy cached locally, and all decision logs are recorded for subsequent auditing; for delays greater than 30 minutes, a service degradation response is returned to the business gateway, guiding the user to retry later to avoid the risk of unauthorized access due to policy inconsistencies.

[0071] S1034: When policy synchronization fails due to network jitter or message loss, the authorization layer first determines the priority of the request by using the X-Priority field in the request header, which has a high, medium, or low value. High-priority requests directly enter the retry queue and use an exponential backoff strategy to re-request the policy center. Medium and low-priority requests are downgraded to local cache decisions, which are executed based on the last successfully synchronized policy snapshot, and X-Policy-Stale:true is added to the response header to indicate to the user that the current policy may not be up-to-date.

[0072] If the retry process fails three times in a row, the request will be recorded as a policy synchronization anomaly and an audit alarm will be triggered, requiring manual intervention by operations and maintenance personnel.

[0073] It should be noted that the authorization layer locates the corresponding policy snapshot storage area through the tenant identifier and extracts the minimum necessary policy fragment based on the requested resource type. The policy snapshot consists of three parts: the RBAC role and permission table, the ABAC attribute rule set, and the effective timestamp. During verification, the authorization layer calculates the hash value of the locally cached snapshot and compares it with the hash value pushed from the policy center. If they do not match, the snapshot is deemed invalid, and synchronization is forcibly triggered.

[0074] The authorization layer selects a decision mode based on the sensitivity level of the request. Low-risk requests are directly matched against the RBAC role and permission table; if the user's role contains the corresponding permissions, a license is quickly returned. High-risk requests trigger the ABAC model; if all conditions are met, access is allowed. If the results of the two models differ, the system prioritizes the ABAC result to ensure the strictness of high-risk operations.

[0075] The authorization layer is responsible for making permission decisions for all business API calls, inter-microservice calls, and cross-system resource access, and returning a Permit or Deny response. This ensures that access permissions and data isolation are strictly managed for each tenant in a multi-tenant and multi-application environment. Its core lies in combining permission declarations in JWT with local policy data to achieve fast and accurate access control.

[0076] Local policy caching involves authorization service instances periodically or event-driven fetching of differentiated snapshots from the policy center, avoiding access to central storage for every decision and achieving millisecond-level decision response. The hybrid decision model combines RBAC and ABAC, employing role mapping for certain static role permissions and combining user attributes, resource attributes, and environmental context for scenarios requiring attribute-level control. Furthermore, the authorization layer collaborates with the service mesh, using circuit breaking and rate limiting strategies to prevent cascading failures under extreme loads, ensuring the continuity and availability of critical business operations.

[0077] When policy synchronization is delayed due to network jitter or message loss, the authorization service will use the last successful snapshot locally and asynchronously retry pulling the update in the background. If multiple retries fail, it will enter read-only mode, allowing continued decision-making based on existing policies to avoid business disruption.

[0078] In some specific embodiments, the authorization layer defines the policy difference condition C={(P i ,P j Strategy P i With strategy P j If mutual exclusion rules exist, monitor policy difference conditions. When a difference is detected, traverse the policy dependency graph using the DFS edge detection algorithm to identify the difference condition pairs and trigger priority adjustment.

[0079] The authorization layer internally defines a policy difference condition C={(Pi,Pj)|policy Pi and policy Pj have a mutual exclusion rule}, which is used to monitor policy conflicts. When a difference is detected, the policy dependency graph is traversed by a depth-first search (DFS) edge detection algorithm to identify conflicting pairs and trigger priority adjustment.

[0080] The authorization layer uses user roles, resource attributes, login time, and IP address as vector dimensions, and calculates a comprehensive score through a tenant-defined policy weight function.

[0081] By combining the static role permissions of RBAC with the attribute matching of ABAC, the final authorization result is generated.

[0082] In the hybrid RBAC / ABAC decision model, a context-based policy fusion logic is added to map user roles, resource attributes, time, geographical location, and device type into decision vectors, and calculate the final authorization result through a tenant-defined policy weight function.

[0083] The formula for calculating the decision vector is: S = w1⋅R + w2⋅A + w3⋅E Where S is the overall score, R is the role permission weight, A is the resource attribute matching degree, E is the environment context adaptation degree, and w1, w2, w3 are tenant-defined dimension weight coefficients; when S≥ preset threshold T, Permit is returned, otherwise Deny is returned.

[0084] When pushing updates, the strategy center only transmits the differences between the local snapshot and the new version. The authorization service parses the patch and then partially updates the cache, rather than replacing the entire cache, which significantly reduces synchronization latency.

[0085] When the Strategy Center pushes an update, it generates a difference package D={new strategy, modified strategy, deleted strategy}. The licensed service resolves the patch and updates the local snapshot as follows: For each new strategy p∈D, add it and insert it into the corresponding position in the snapshot; Modify the strategy p∈D to replace the old version of the attribute value; For deletion policy p∈D, remove from the snapshot.

[0086] Version vectors are used to record snapshot update history to ensure data consistency across multiple nodes.

[0087] In this way, when the policy center pushes an update, it only transmits the differences between the local snapshot and the new version. The authorization service parses the patch and then partially updates the cache, rather than replacing the entire cache, which significantly reduces synchronization latency.

[0088] In one embodiment of the present invention, based on a strategy center, the following will provide a non-limiting description of an embodiment of the strategy center and its specific implementation.

[0089] The policy center creates an independent policy storage space for each tenant, such as a database partition with the tenant ID as the key, storing the tenant role and permission table, attribute rule set, and global default policy. These are linked to each tenant's space via symbolic links or references to avoid duplicate storage. Tenant-specific policies support custom extended fields, ensuring the isolation and sharing of multi-tenant policies.

[0090] The policy center adopts a version control model similar to Git. Each policy change generates a new version, with the version number format being tenant ID-timestamp-serial number, and a change log is recorded.

[0091] The policy center supports policy branch management, such as development branches and production branches. Tenants can choose to synchronize policies from a specified branch to avoid untested policies in development affecting the production environment. When merging versions, the system automatically detects differences. If the same line in the same policy file is modified by different tenants, the system will prompt the administrator to resolve the issue manually.

[0092] When a policy is updated, the policy center generates an incremental difference packet, which is broadcast to all authorized nodes via the message bus. The difference packet contains a version number, change type, a list of affected tenants, and specific changes. Authorized nodes only retrieve difference packets relevant to their own tenants, reducing network traffic, and verify the packet's signature to ensure integrity.

[0093] The policy center supports canary deployments based on tenant proportions or custom tags. After deployment, the system automatically collects access logs from canary tenants, such as the number of permission denials and abnormal access patterns, and evaluates the impact of policy changes using a machine learning model. If the evaluation results exceed a preset threshold, a rollback is triggered, restoring the canary tenants' policies to the previous version and notifying the administrator; if the evaluation passes, the deployment scope is gradually expanded until it takes full effect.

[0094] The policy center addresses the complexity of policy management in multi-tenant environments by providing centralized, secure, and flexible policy management through intelligent storage, version management, incremental broadcasting, and canary verification.

[0095] It should be noted that in the policy center, each tenant has an independent policy storage space to store tenant-defined policies; public policies, such as those with default data:read permissions for all users, are stored in a globally shared space and linked to each tenant's space via symbolic links or metadata references. Flexible expansion of tenant policies is supported.

[0096] The strategy center draws inspiration from code version control systems, generating a unique version number for each strategy change and recording a complete change log. During version merging, the system uses text comparison algorithms to detect differences and generates a discrepancy report for administrators to manually resolve, ensuring the clarity and traceability of version evolution.

[0097] When updating policies, the policy center generates incremental difference packets based on the JSONPatch difference algorithm. These packets contain only the changed policy fragments, not the entire policy. The difference packets are broadcast to all authorized nodes via the message bus. Authorized nodes only pull the difference packets relevant to their own tenants, significantly reducing network traffic. Simultaneously, the difference packets are digitally signed using the policy center's private key, and authorized nodes verify the signature using their public key, ensuring the integrity and trustworthiness of the policy update's source.

[0098] The policy center supports canary deployments based on tenant proportions or custom tags. After deployment, the system collects access logs from canary tenants using a log collection component and extracts key metrics. These metrics are then fed into a machine learning model to assess the impact of policy changes, ensuring that the risks associated with policy changes are manageable.

[0099] In one embodiment of the present invention, based on an audit monitoring layer, the following will provide an embodiment of an audit monitoring layer and describe its specific implementation in a non-limiting manner.

[0100] After receiving the logs, the audit and monitoring layer performs multi-tenant isolated storage of the logs based on the global transaction ID and tenant identifier (X-Tenant-ID) injected from the unified portal layer.

[0101] Each tenant's logs are stored in an independent Elasticsearch index, and cross-tenant call relationships are recorded in the log metadata to ensure the traceability and isolation of multi-tenant logs. At the same time, a unique log tracing chain ID is generated for each tenant, linking the logs of all related requests of that tenant, solving the problem of difficulty in tracing caused by log mixing in a multi-tenant environment.

[0102] The audit and monitoring layer automatically adjusts the data anonymization strategy based on the tenant's business type and data sensitivity level.

[0103] For example, the bank card number field of financial tenants is masked, and the patient name field of medical tenants is hashed. At the same time, temporary masking based on request context is supported, and the masking rules are synchronized to the audit and monitoring layer in real time through the policy center to ensure that the masking strategy matches the business needs.

[0104] This embodiment builds upon OpenTelemetry tracing by adding link anomaly detection logic to the audit and monitoring layer. By analyzing the time distribution, error rate, and resource consumption of the call links, abnormal links are marked, and the specific input and output parameters and service version information of each node are recorded, providing more complete contextual information for anomaly troubleshooting.

[0105] The audit and monitoring layer uses an LSTM time series model to learn normal behavior patterns by combining historical log data. The LSTM time series model receives new log data in real time and updates the normal behavior baseline; when behavior deviating from the baseline is detected, the alarm policy is adjusted and the operations and maintenance personnel are notified via email / SMS.

[0106] As can be seen, the audit and monitoring layer divides and stores logs by tenant dimension through global transaction ID and tenant identifier, with each tenant's logs indexed independently to avoid cross-interference between logs from different tenants. At the same time, by linking all related request logs of the same tenant through the trace chain ID, even if the logs are scattered across different service nodes, the entire process can be quickly reconstructed through the trace chain ID, solving the problem of time-consuming tracing caused by mixed multi-tenant logs in traditional solutions.

[0107] The audit and monitoring layer retrieves tenant masking policies from the policy center and adjusts the masking strength based on the request context. The layer uses machine learning models to learn normal behavior patterns. These models support online incremental training, preventing increased false alarm rates due to changes in business models and improving alert accuracy.

[0108] The audit and monitoring layer is responsible for the collection, storage, and analysis of logs and events across the entire chain, from a unified entry point to each functional module, and triggers real-time alerts to support security operations and compliance auditing. Especially in environments with multiple resources and integrated applications, the audit and monitoring layer needs to ensure the traceability of operational behaviors and access records among tenants and monitor data flow across applications. It generates global transaction IDs using the OpenTelemetry standard and appends them to every request and message to achieve cross-service call chain tracing. Log collection components (Fluentd / Filebeat) aggregate structured and unstructured logs to the Elasticsearch / Kibana platform and store sensitive data long-term after anonymization. The alert rule base allows for customization of thresholds such as login failure count, unauthorized access attempt rate, and policy delivery failures, and notifies relevant operations personnel via email, SMS, or enterprise messaging platforms to ensure rapid response and handling of security incidents. Audit and monitoring not only records events but also calculates key performance indicators (such as average authentication latency, average decision latency, and alert response time) in real time; combined with machine learning models, it analyzes login patterns and access behaviors to predict abnormal behavior and trigger proactive defenses before potential threats occur.

[0109] Furthermore, as a refinement and extension of the specific implementation method of the above-mentioned multi-tenant centralized authentication and authorization system embodiment, an end-to-end closed loop is constructed around four typical processes in the multi-tenant centralized authentication and authorization system: user login and token issuance, API access and permission verification, policy updates and canary release auditing and alarms. The following adds abnormal scenario handling and optional verification steps while retaining the node-based approach, to improve the integrity and operability of the business process.

[0110] (1) Request entry and tenant identification: Users access the unified portal's login address (e.g., https: / / portal.example.com / {tenant} / login) through the Web, mobile or third-party applications. When the portal receives a request, it prioritizes parsing the domain name suffix, URL prefix or custom HTTP header to accurately inject the X-Tenant-ID. If identification fails, it returns a unified error page and triggers an operation and maintenance alarm.

[0111] (2) Credential verification and multi-factor authentication: The portal forwards the login request containing the tenant context to the authentication service. The authentication service selects the corresponding identity source according to the tenant configuration for preliminary password verification. If the tenant policy requires it, a second-factor authentication is performed. For first-time logins, the system can force the user to complete a password reset or security question configuration.

[0112] (3) JWT generation, session binding, and optional device binding: After successful verification, the token manager generates a JWT containing the tenant ID, user ID, role, permission declaration, and device fingerprint, and returns it in the form of HTTPOnlyCookie or response body. The portal establishes a mapping of SessionID, JWT, DeviceID, and SessionID in the Redis cluster. For high-security tenants, the device binding option can be enabled to restrict the same credential to be effective only on the registered device.

[0113] (4) Audit and logging: The portal and authentication service report three types of audit events: login attempt, successful multi-factor authentication, and token issuance. The link tracer assigns a global transaction ID to this login and marks the number of abnormal retries, MFA type and device fingerprint in the log to facilitate subsequent security backtracking and compliance audit.

[0114] For API calls and permission verification, the following methods are involved: (1) Token verification and blacklist check: All subsequent requests automatically carry JWT. The unified portal performs signature verification, validity period check and blacklist query in sequence at the gateway layer. If the verification fails, it returns HTTP401 / 403 and records the reason for failure and the source IP in the audit system.

[0115] (2) Context injection and load routing: After verification, the portal extracts X-Tenant-ID, X-User-ID, X-Roles and X-Permissions from JWT and injects them as HTTP headers or gRPCMetadata used by downstream services. Then, traffic is routed to the corresponding business cluster according to the tenant isolation policy.

[0116] (3) Local policy decision-making and anomaly degradation: The authorization service instance loads the locally cached policy snapshot and performs a mixed RBAC / ABAC decision with the JWT declaration and request context. If the policy synchronization delay or network jitter causes the decision engine to be out of sync with the center, the system will fall back to the last effective policy for judgment and asynchronously trigger policy synchronization retry; if it fails multiple times, it will enter read-only judgment mode, continue to allow existing permission requests to ensure that the business is not interrupted, and report an alarm.

[0117] (4) Decision return and business response: The authorization result is returned to the business gateway in the form of Permit or Deny; for Deny requests, the system will provide a unified error code and a friendly prompt, and write key fields such as user, resource, time, and reason into the audit log; for Permit requests, the business service continues to execute the business logic and carries a simple audit label in the response header.

[0118] The strategy update and canary release method includes the following steps: (1) After the administrator completes the rule definition in the policy center through drag-and-drop interface or YAML / JSON script, he / she initiates multi-level approval (automatic approval rules can be configured to speed up the process). If the approval is successful, a new version number is generated and pushed to the pre-release environment.

[0119] (2) The policy center publishes version update events to the message bus. The event includes tenant scope, instance tags, and policy difference package information. After receiving the event, the authorized service nodes that subscribe to the event only perform merge updates on the differences, without having to pull the entire package, which significantly reduces network and storage pressure.

[0120] (3) Complete the gray-scale test within the selected tenant or test node range. The system verifies the policy behavior based on both simulated traffic and real business, and provides a real-time monitoring panel in the policy center. After the test is successful, it can be promoted to the full range with one click. If a policy defect is found, the administrator can trigger a rollback operation in the center interface. The system will restore the old policy and perform a full consistency check and cleanup after the rollback (including cache refresh and temporary log deletion).

[0121] The system implementation of this invention includes the integration and implementation of programming languages, development frameworks, distributed storage, and data analysis technologies. After system development is completed, multi-level testing is conducted to verify the system's functionality, stability, and compatibility, ensuring its reliability and efficiency in practical applications.

[0122] The system's deployment topology on the Kubernetes cluster includes the container specifications, node distribution, network and storage solutions for each microservice; it also lists the main technology stack and security components.

[0123] The following are embodiments of the multi-tenant centralized authentication and authorization method provided in this disclosure. This method belongs to the same inventive concept as the multi-tenant centralized authentication and authorization system in the above embodiments. For details not described in detail in the embodiments of the multi-tenant centralized authentication and authorization method, please refer to the embodiments of the multi-tenant centralized authentication and authorization system described above.

[0124] like Figure 2 As shown, the method includes: Step 201: The user terminal sends a service access request to the unified portal layer. After receiving the request, the unified portal layer performs a tenant context injection operation and determines the tenant subject to which the current request belongs based on the tenant identification information carried in the request. Then, it performs route parsing processing, matching the corresponding service processing path according to the service type and target resource address of the request to form the service request information after preliminary processing. Step 202: After the business request information is processed by the unified portal layer, the resource integration and application integration processing flow is initiated; It calls upon the underlying infrastructure resource pool to schedule and integrate computing, storage, and network resources; it standardizes the conversion of heterogeneous interfaces of different business systems, and uses the adapter pattern to achieve unified conversion and protocol adaptation of cross-system data formats, forming business processing requests that conform to subsequent processing specifications. Step 203: The authentication layer compares and verifies the user credentials in the business processing request with the pre-stored authentication information to generate a user identity authentication result; based on the authentication result and combined with the permission policy data issued by the policy center, it performs permission verification on the user request and generates authorization information. Step 204: Based on the authorization information, the policy center obtains policy snapshot data from the cache layer, checks the Token blacklist, and verifies whether the identity token carried by the authorization information exists in the blacklist of invalid, stolen, or illegally used tokens; combining the rule matching results of the policy snapshot with the Token blacklist verification results, a business execution policy instruction containing access control instructions is generated. Step 205: Allocate resources and schedule processes for business requests according to business execution strategy instructions; Specifically, based on the computing resource requirements allocated in the business execution strategy instructions, the corresponding data interaction channels are enabled according to the interface call permissions; at the same time, key audit elements in the strategy execution process are transmitted to the audit monitoring layer in real time. Step 206: The audit and monitoring layer logs and monitors the behavior of key audit elements during the strategy execution process.

[0125] The method of this invention proposes a collaborative architecture of a unified portal, an integration layer, authentication services, authorization services, a policy center, and audit monitoring. The method adds an integration layer under the unified portal, which is specifically responsible for connecting with various third-party resources (APIs, databases, middleware services, etc.) and multiple business applications to achieve protocol adaptation, data conversion, and process orchestration. At the same time, relying on tenant context injection and routing, it ensures that the integration resources and application instances of each tenant are strictly isolated, thus building a reliable security boundary.

[0126] The method benefits from localized policy snapshots, event-driven differential updates, and a decentralized call architecture, resulting in an average response latency of less than 5ms for authorization decisions and an authentication and issuance latency of no more than 50ms. Combined with pre-verification and rate limiting strategies at the integration layer, the system can stably support hundreds of thousands to millions of authentication requests and tens of millions of authorization calls per day, meeting the performance requirements of high-concurrency, multi-tenant scenarios.

[0127] The policy center supports canary deployments grouped by tenant, resource type, or application instance, enabling differentiated policy verification for different tenants. During one-click rollback, not only are policies restored, but integration layer cache and temporary logs are also automatically cleared, ensuring the continuity of integrated resource calls and zero business interruption.

[0128] The system architecture is based on Kubernetes and containerized deployment in multiple private clouds across different regions. Combined with service mesh and service registration and discovery, it enables automatic scaling and load balancing of authentication / authorization services and the integration layer. Active-Active / Active-Standby disaster recovery configurations can complete failover within 30 seconds. The auditing and monitoring layer not only collects logs from the unified portal and core services but also integrates the call chains of the integration layer and uses machine learning models to detect and predict anomalies in cross-resource and cross-application access behavior. Operations personnel can quickly locate integration call bottlenecks and security risks in a multi-tenant environment through a visual dashboard.

[0129] Leveraging a highly decoupled unified portal and a flexible, configurable integration layer, this invention allows access to multiple resources and applications without requiring large-scale modifications to existing business systems. The SDK / API documentation and examples provided to developers, along with comprehensive functional verification, performance testing, and security penetration testing reports, offer ample feasibility assurance for project implementation and significantly shorten the cycle from design to deployment.

[0130] like Figure 3 As shown, this application also provides an electronic device, including a display module 103, a memory 102, a processor 101, and a computer program stored in the memory and executable on the processor 101. When the processor 101 executes the program, it implements the steps of a multi-tenant centralized authentication and authorization system.

[0131] In embodiments of the present invention, electronic devices include, but are not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments described and / or claimed herein.

[0132] In this embodiment, processor 101 may be implemented using at least one of an application-specific integrated circuit, a programmable logic device, a field-programmable gate array, a processor, a controller, a microcontroller, a microprocessor, or an electronic unit designed to perform the functions described herein. In some cases, such an implementation may be implemented within a controller. For software implementation, implementations such as processes or functions may be implemented with separate software modules that allow the performance of at least one function or operation. Software code may be implemented by a software application (or program) written in any suitable programming language, and the software code may be stored in memory and executed by the controller.

[0133] The display module 103 is used to display information input by the user or information provided to the user. The display module 103 may include a display panel, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like.

[0134] The memory 102 can be used to store software programs and various data. The memory 102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0135] This application also provides a storage medium on which a computer program is stored, which, when executed by a processor, implements the multi-tenant centralized authentication and authorization system.

[0136] The storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0137] In a storage medium, a readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0138] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A multi-tenant centralized authentication and authorization system based on, The system comprises a unified portal layer, an authentication layer, an authorization layer, a policy center and an audit monitoring layer; ​ The unified portal layer receives user requests, identifies and injects tenant identification, performs WAF rule verification, JWT signature verification and Token blacklist check, and intercepts illegal traffic and maintains session state; The authentication layer checks user or client credentials for different identity sources, generates and issues JWT, and monitors token life cycle; The authorization layer extracts the permission declaration in the JWT and the locally cached policy snapshot, combines the RBAC and ABAC hybrid decision model to make permission judgment, and returns Permit or Deny result; The policy center provides centralized storage, version management and visual editing of multi-tenant policies, and broadcasts policy updates to each authorization node; The audit monitoring layer logs and monitors key audit elements in the policy execution process, and predicts and alarms abnormal behavior.

2. The multi-tenant centralized authentication and authorization system according to claim 1, wherein The unified portal layer receives user requests and parses tenant identification information in the order of preset priority, checks tenant ID in custom HTTP header, tenant prefix in URL path, and domain suffix, and returns error page and triggers alarm if all fail; Synchronously perform WAF rule verification and JWT signature verification, WAF performs pattern matching based on predefined feature string to intercept attack requests, and JWT verification uses HSM or KMS managed private key to verify signature and check token validity period and issuer; Perform Token blacklist linkage check, maintain blacklist set through distributed cache, and check jti field of JWT to determine whether to reject the request; Session state initialization and consistency maintenance are performed, SessionID is generated and bound with JWT, stored in distributed cache, written into Cookie in user browser, and Cache-Aside mode is used to maintain session state.

3. The multi-tenant centralized authentication and authorization system according to claim 1, wherein After the authentication service receives the login request forwarded by the unified portal based on the authentication service, according to the tenant pre-configuration information, the corresponding adapter module is called to complete the credential standardization extraction; After the basic credential verification is passed, the authentication service decides whether to trigger factor verification according to tenant policy and user behavior analysis; when verifying, the authentication service and MFA service interact through a TLS encrypted channel to verify the validity of the factor, and record the MFA verification result to the audit log; The authentication layer generates a secure signature in the JWT individualization declaration; After verification, the authentication service generates a JWT payload containing tenant ID, user ID, role mapping table from tenant predefinition, permission declaration, device fingerprint and MFA verification status; The authentication service maintains the Token blacklist stored in the distributed cache, supports immediate revocation operation.

4. The multi-tenant centralized authentication and authorization system according to claim 1, wherein After the authorization layer receives the API call request, it extracts the differentiated policy subset strongly related to the request from the locally cached policy snapshot according to the tenant identifier and resource type in the request; The policy snapshot is stored by the policy center in a tenant-isolated manner, and after extraction, the authorization layer verifies the consistency of the version number of the policy snapshot with the latest version of the policy center, and checks the expiration time of the snapshot; After verifying the validity of the policy snapshot, the authorization layer selects the decision mode according to the sensitive level of the request; for low-risk requests, the RBAC model is preferred to quickly match user roles and predefined permissions; For high-risk requests, trigger the ABAC model to conduct conditional evaluation combined with user attributes, resource attributes, and environmental context; If the results of the two models differ, the ABAC result is used as the final result; The authorization layer maintains a long connection heartbeat with the policy center to regularly obtain the latest version number from the policy center.

5. The multi-tenant centralized authentication and authorization system according to claim 1, wherein The policy center creates an independent policy storage space for each tenant and associates it to each tenant space through soft links or reference methods. Tenant-specific policies support custom extension fields; The policy center uses a Git-like version control model, each policy change generates a new version, and records the change log; The policy center supports policy branch management, and tenants can choose to synchronize policies from a specified branch; when merging versions, the system detects differences and prompts administrators to manually resolve them; When the policy center updates the policy, it generates an incremental difference package and broadcasts it to each authorization node through the message bus; the authorization node only pulls the difference package related to its own tenant and verifies the signature of the difference package to ensure its integrity.

6. The multi-tenant centralized authentication and authorization system according to claim 1, wherein After the audit and monitoring layer receives the log, it performs multi-tenant isolation storage based on the global transaction ID and tenant identifier injected from the unified portal layer; Each tenant's log is stored in an independent Elasticsearch index, and the cross-tenant call relationship is recorded in the log metadata; a unique log tracking chain ID is generated for each tenant, which concatenates all associated requests of the tenant; The audit and monitoring layer learns normal behavior patterns based on LSTM time series models combined with historical log data; When detecting behavior that deviates from the baseline, adjust the alarm strategy and notify the operations personnel through email or SMS.

7. The multi-tenant centralized authentication and authorization system according to claim 1, wherein The authorization layer defines policy difference conditions C={(Pi, Pj) | policy Pi and policy Pj have mutual exclusion rules} to monitor policy differences; when detecting differences, it uses a depth-first search (DFS) edge detection algorithm to traverse the policy dependency graph, identify conflicting pairs, and trigger priority adjustments; In the hybrid RBAC / ABAC decision model, context-based policy fusion logic is added to map user roles, resource attributes, and time, geographic location, and device type into a decision vector, and calculate the final authorization result through a tenant-defined policy weight function; The calculation formula of the decision vector is: S=w1⋅R+w2⋅A+w3⋅E Wherein, S is the comprehensive score, R is the role permission weight, A is the resource attribute matching degree, E is the environment context adaptation degree, w1, w2, w3 are the dimension weight coefficients customized by the tenant; When the policy center pushes an update, the policy center generates a difference package D={new policy, modified policy, deleted policy}; The authorization service parses the patch and updates the local snapshot to: For a new policy p e Dnew, insert it into the corresponding position of the snapshot; For a modified policy p e Dmodified, replace the old version attribute value; For a deleted policy p e Ddeleted, remove it from the snapshot.

8. A multi-tenant centralized authentication and authorization method based on, characterized in that, The method is implemented based on the multi-tenant centralized authentication and authorization system according to any one of claims 1 to 7. The method comprises: Step 201: The user terminal sends a business access request to the unified portal layer, the unified portal layer receives the request, performs tenant context injection operation, determines the tenant subject to which the current request belongs according to the tenant identification information carried by the request, then performs routing analysis processing, matches the corresponding business processing path according to the business type and target resource address of the request, and forms the business request information after preliminary processing; Step 202: The business request information processed by the unified portal layer starts the resource integration and application integration processing flow; Call the underlying infrastructure resource pool to complete the scheduling and capability integration of computing resources, storage resources and network resources; standardize the heterogeneous interfaces of different business systems, realize the unified conversion of cross-system data format and protocol adaptation through the adapter mode, and form the business processing request conforming to the subsequent processing specification; Step 203: The authentication layer compares and verifies the user credentials in the business processing request with the pre-stored authentication information, generates user identity authentication result; based on the authentication result, combined with the permission policy data issued by the policy center, the user request is verified for permission, and authorization information is generated; Step 204: The policy center obtains the policy snapshot data from the cache layer based on the authorization information, checks the Token blacklist, verifies whether the identity token carried by the authorization information exists in the blacklist list of invalid, stolen or illegal use; based on the rule matching result of the policy snapshot and the Token blacklist verification conclusion, a business execution strategy instruction containing permission control instruction is generated; Step 205: According to the business execution strategy instruction, the business request is allocated with resources and scheduled; Wherein, according to the computing resource demand allocation instance in the business execution strategy instruction, the corresponding data interaction channel is enabled according to the interface calling permission; at the same time, the key audit elements in the strategy execution process are transmitted to the audit monitoring layer in real time; Step 206: The audit monitoring layer records the log and monitors the behavior of the key audit elements in the strategy execution process.

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to realize the multi-tenant centralized authentication and authorization system according to any one of claims 1 to 7.

10. A storage medium having stored thereon a computer program, characterized in that The computer program is executed by the processor to realize the multi-tenant centralized authentication and authorization system according to any one of claims 1 to 7.

Images