{"id":11629,"date":"2025-12-15T17:37:13","date_gmt":"2025-12-15T06:37:13","guid":{"rendered":"https:\/\/geoffreychen.com\/?p=11629"},"modified":"2025-12-15T17:37:13","modified_gmt":"2025-12-15T06:37:13","slug":"architectural-design-for-commercializing-multi-tenant-identity-platforms-while-ensuring-security","status":"publish","type":"post","link":"https:\/\/geoffreychen.com\/zh\/architectural-design-for-commercializing-multi-tenant-identity-platforms-while-ensuring-security\/","title":{"rendered":"Architectural Design for Commercializing Multi-Tenant Identity Platforms While Ensuring Security"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">By Geoffrey Chen<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Decoupling, Event-Driven, and Minimal Dependence: An Architectural Design for Commercializing Multi-Tenant Identity as a Service (IDaaS) Platforms While Ensuring Security<\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"abstract\">Abstract<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">As Identity as a Service (IDaaS) becomes a critical component of SaaS infrastructure, building a Multi-Tenant Identity Provider (IdP) requires not only meeting stringent security and scalability requirements but also supporting flexible, high-precision monetization models. Traditional IdP architectures face challenges of high coupling and limited scalability when handling fine-grained authorization attributes and high-frequency metering events.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This paper proposes an innovative&nbsp;<strong>Decoupled, Event-Driven Architecture (DEDA)<\/strong>, using the&nbsp;<strong>Smallsoft Identity platform<\/strong>&nbsp;as a design case study. The core of the DEDA architecture lies in the physical and logical decoupling of the high-security-sensitive&nbsp;<strong>Core Identity Service<\/strong>&nbsp;from the high-commercial-sensitive&nbsp;<strong>Metering Service<\/strong>&nbsp;and&nbsp;<strong>Attribute Synchronization Services<\/strong>. This design strictly adheres to&nbsp;<strong><code>TenantId<\/code>&nbsp;Isolation<\/strong>&nbsp;and the&nbsp;<strong>Principle of Least Privilege<\/strong>&nbsp;to ensure security in a multi-tenant environment. It leverages the&nbsp;<strong>Identity Event Bus<\/strong>&nbsp;and&nbsp;<strong>Fine-Grained Claims<\/strong>&nbsp;integration to support flexible billing based on MAU, transactions, and AI-enhanced features. This design aims to provide Service Providers (SPs) with high-accuracy, reliable commercial input data for their billing and authorization systems without compromising the IdP&#8217;s core security boundary or depending on the SP&#8217;s end-user billing system, thereby enabling the secure commercialization of IDaaS platforms.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Keywords:<\/strong>&nbsp;Multi-Tenant Identity, IdP Architecture, Commercialization, Metering, Authorization Attributes, OAuth 2.0, OpenID Connect, Microservices.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"1-introduction\">1. Introduction<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"11-evolution-of-identity-services-and-commercialization\">1.1 Evolution of Identity Services and Commercialization<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In the era of cloud computing and microservices, identity authentication and authorization have evolved from back-end functionalities to front-line capabilities that determine the market competitiveness and security compliance of SaaS products. An excellent IdP must manage the user lifecycle, support complex federation and Single Sign-On (SSO), and integrate with the growing number of AI-driven threat detection services.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This expansion of capabilities imposes a new requirement on IdP architecture:&nbsp;<strong>Commercialization<\/strong>. The IdP is no longer purely a cost center but a potential profit center. To implement flexible business models, the IdP must be able to precisely meter user activity and charge based on differentiated features (e.g., biometrics, high availability guarantees). However, coupling commercial logic and metering systems directly into the core authentication flow introduces significant security risks, performance bottlenecks, and reduces system maintainability.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"12-challenges-and-necessity\">1.2 Challenges and Necessity<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Achieving secure commercialization in an IDaaS platform requires overcoming the following key challenges:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Security Isolation vs. Performance:<\/strong>\u00a0Ensuring the physical and logical isolation of data and configurations between different SPs, while maintaining low latency and high throughput for the core authentication path.<\/li>\n\n\n\n<li><strong>Billing Dependency Risk:<\/strong>\u00a0How to provide SPs with accurate billing data (e.g., User A&#8217;s 5th MFA transaction this month) while ensuring the IdP does not create a tight coupling or runtime dependency on the SP&#8217;s end-user billing system.<\/li>\n\n\n\n<li><strong>Fine-Grained Authorization Data Transfer:<\/strong>\u00a0A secure, standardized mechanism is necessary to transfer user authorization attributes (e.g., subscription level, quota limits) stored in the IdP to the SP&#8217;s application layer, to serve as the basis for SP authorization decisions.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"13-contributions\">1.3 Contributions<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The DEDA architecture model proposed in this paper addresses the above challenges with the following contributions:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Proposal of DEDA Architecture:<\/strong>\u00a0A microservice-based, event-driven IdP architecture design that decouples high-security authentication from high-commercial-value metering.<\/li>\n\n\n\n<li><strong>Minimal Dependency Input Mechanism:<\/strong>\u00a0Definition of a dual mechanism\u2014based on the\u00a0<strong>Identity Event Bus<\/strong>\u00a0and\u00a0<strong>Custom Claims<\/strong>\u2014to enable the IdP to provide billing and authorization input data to the SP with minimal dependency.<\/li>\n\n\n\n<li><strong>Design Case Study:<\/strong>\u00a0Using the proposed\u00a0<strong>Smallsoft Identity platform<\/strong>\u00a0design as an example, detailed demonstration of the DEDA architecture&#8217;s design for high-value feature metering and business logic decoupling.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"2-limitations-of-traditional-architecture-and-design-principles\">2. Limitations of Traditional Architecture and Design Principles<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"21-issues-with-traditional-coupled-architectures\">2.1 Issues with Traditional Coupled Architectures<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">[Content Omitted for Brevity]<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"22-core-deda-design-principles\">2.2 Core DEDA Design Principles<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The DEDA architecture adheres strictly to the following principles:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Separation of Concerns:<\/strong>\u00a0Identity management, metering, and auditing must be independent microservices.<\/li>\n\n\n\n<li><strong>Principle of Least Privilege:<\/strong>\u00a0Any service (especially the Metering Service) is only granted the minimal privileges required to perform its task.<\/li>\n\n\n\n<li><strong>Eventual Consistency:<\/strong>\u00a0Minor short-term latency in metering data relative to the core identity state is acceptable in exchange for the high availability and high throughput of the core identity service.<\/li>\n\n\n\n<li><strong>Open Standard Communication:<\/strong>\u00a0Authentication and authorization information transfer must be based on open standards like OAuth 2.0, OpenID Connect, and SCIM.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"3-the-deda-architecture-model-decoupling-and-metering-implementation\">3. The DEDA Architecture Model: Decoupling and Metering Implementation<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The core of the DEDA architecture consists of three independently operating service components communicating via asynchronous messaging: the&nbsp;<strong>Core Identity Service<\/strong>, the&nbsp;<strong>Identity Event Bus<\/strong>, and the&nbsp;<strong>Commercial Metering Service<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"31-core-identity-service\">3.1 Core Identity Service<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The Core Identity Service acts as the IdP&#8217;s security boundary. It is responsible for user credential validation, session management, and token issuance.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\" id=\"311-implementation-of-tenant-isolation\">3.1.1 Implementation of Tenant Isolation<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Mandatory TenantId Isolation:<\/strong>\u00a0<strong>In the Smallsoft Identity design<\/strong>, all user tables, configuration tables, and audit logs must contain a mandatory\u00a0<code>TenantId<\/code>\u00a0column. Interceptors (e.g., AOP) in the Data Access Layer (DAL) enforce the\u00a0<code>TenantId<\/code>\u00a0filter on all database operations.<\/li>\n\n\n\n<li><strong>Resource Isolation:<\/strong>\u00a0<strong>The Smallsoft Identity design<\/strong>\u00a0proposes providing independent subdomains for each paying tenant (SP) and storing MFA keys and encryption salts in an HSM\/Vault partitioned based on\u00a0<code>TenantId<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"32-identity-event-bus\">3.2 Identity Event Bus<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The Identity Event Bus (e.g., using Kafka or similar technologies) serves as the sole data sharing mechanism within the IdP.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Real-Time Event Publishing:<\/strong>\u00a0Whenever a chargeable or auditable key identity event occurs (<code>AUTHN_SUCCESS<\/code>,\u00a0<code>MFA_REQUESTED<\/code>,\u00a0<code>USER_REGISTERED<\/code>), the Core Identity Service immediately generates and publishes an event to the bus.<\/li>\n\n\n\n<li><strong>Non-Blocking Design:<\/strong>\u00a0This asynchronous design is crucial for\u00a0<strong>Smallsoft Identity<\/strong>\u00a0to achieve low authentication latency. The authentication flow is not blocked while waiting for downstream metering service writes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"33-commercial-metering-service\">3.3 Commercial Metering Service<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">This service focuses exclusively on commercial value capture and is physically and logically separate from the Core Identity Service.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Function:<\/strong>\u00a0It consumes the event stream from the Identity Event Bus to calculate and aggregate the metrics used for the IdP&#8217;s billing of SPs.<\/li>\n\n\n\n<li><strong>Multidimensional Metering Metrics:<\/strong><strong>The Smallsoft Identity design<\/strong>\u00a0supports the following metrics:\n<ul class=\"wp-block-list\">\n<li><strong>Base Metering:<\/strong>\u00a0MAU (unique user IDs based on\u00a0<code>AUTHN_SUCCESS<\/code>\u00a0events).<\/li>\n\n\n\n<li><strong>High-Value Transaction Metering:<\/strong>\u00a0Successful MFA transactions, custom policy engine executions.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Data Security:<\/strong>\u00a0The metering database only stores aggregated data (e.g., Tenant A&#8217;s MAU count), minimizing the risk of exposure of sensitive user data that could be used for identity restoration.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"4-security-and-commercial-input-mechanisms\">4. Security and Commercial Input Mechanisms<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The DEDA architecture provides the necessary input for SP billing systems through strict interface and data isolation, adhering to the principle of minimal dependency.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"41-sp-billing-input-claims-as-input-mechanism\">4.1 SP Billing Input: Claims-as-Input Mechanism<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The&nbsp;<strong>Smallsoft Identity<\/strong>&nbsp;design securely transfers authorization attributes via Custom Claims within OAuth 2.0 Access Tokens and OIDC ID Tokens.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Custom Claims Design:<\/strong>\u00a0<strong>In the Smallsoft Identity proposal<\/strong>, SPs can pre-define custom Claims to be carried in the token via the management console (e.g.,\u00a0<code>sp_data_quota<\/code>).<\/li>\n\n\n\n<li><strong>Design Case:<\/strong>\u00a0When User A logs in, the\u00a0<strong>Smallsoft Identity<\/strong>\u00a0token issuance service retrieves the user&#8217;s\u00a0<code>SubscriptionLevel<\/code>\u00a0as\u00a0<code>\"Premium\"<\/code>. The token will include the Claim\u00a0<code>{\"SubscriptionLevel\": \"Premium\"}<\/code>. The SP&#8217;s application relies solely on this Claim for authorization.\u00a0<strong>&#8220;Premium&#8221; is merely an opaque string at the IdP level, serving as an authorization result with no logical meaning<\/strong>; all pricing and feature unlocking logic is executed by the SP, effectively eliminating IdP dependency on the SP&#8217;s billing system.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"42-real-time-attribute-synchronization-application-of-scim-protocol\">4.2 Real-Time Attribute Synchronization: Application of SCIM Protocol<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">To ensure the authorization attributes stored in the IdP align with the SP&#8217;s commercial source of truth,&nbsp;<strong>Smallsoft Identity<\/strong>&nbsp;integrates standard SCIM interfaces.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>SCIM for Attribute Updates:<\/strong>\u00a0<strong>Smallsoft Identity<\/strong>\u00a0plans to provide a SCIM Endpoint allowing the SP&#8217;s CRM\/billing system to send a secure PATCH request to the IdP, updating the user&#8217;s attributes (e.g., changing\u00a0<code>SubscriptionLevel<\/code>\u00a0from &#8220;Basic&#8221; to &#8220;Enterprise&#8221;).<\/li>\n\n\n\n<li><strong>Unidirectional Control:<\/strong>\u00a0This synchronization is\u00a0<strong>SP-driven<\/strong>; the IdP acts only as an attribute store and distribution point.\u00a0<strong>The SP&#8217;s End User Billing system should not have any dependency on the IdP beyond authentication and authorization functionality<\/strong>, making the SCIM interface the only necessary and controlled API dependency.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"43-billing-notification-opening-the-identity-event-bus-to-sps\">4.3 Billing Notification: Opening the Identity Event Bus to SPs<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Smallsoft Identity<\/strong>&nbsp;plans to offer a Webhook service to forward specific events from the Identity Event Bus to a pre-configured URL for the SP.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>SP Billing Triggers:<\/strong>\u00a0SPs can subscribe to\u00a0<code>USER_REGISTERED<\/code>\u00a0events (to start a free trial period) or\u00a0<code>PROFILE_UPDATED<\/code>\u00a0events (to re-evaluate the subscription status). These events carry non-sensitive\u00a0<code>User ID<\/code>\u00a0and\u00a0<code>Tenant ID<\/code>. Upon receipt, the SP&#8217;s billing backend can immediately trigger its internal logic without requiring additional authentication API calls to the IdP.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"5-design-and-case-study\">5. Design and Case Study<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"51-design-case-metering-of-ai-enhanced-authentication-in-smallsoft-identity\">5.1 Design Case: Metering of AI-Enhanced Authentication in Smallsoft Identity<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The&nbsp;<strong>Smallsoft Identity<\/strong>&nbsp;design incorporates AI-enhanced Adaptive Authentication based on machine learning models.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Process:<\/strong>\u00a0During user login, the Core Identity Service calls a separate\u00a0<strong>AI Risk Assessment Microservice<\/strong>.<\/li>\n\n\n\n<li><strong>Events and Metering:<\/strong>\n<ol class=\"wp-block-list\">\n<li><strong>Smallsoft Identity<\/strong>\u00a0immediately publishes a\u00a0<strong><code>RISK_SCORE_COMPUTED<\/code><\/strong>\u00a0event after each AI service call. The event payload includes the\u00a0<code>TenantId<\/code>\u00a0and the\u00a0<code>Score<\/code>.<\/li>\n\n\n\n<li>The Commercial Metering Service consumes this event and counts the transaction toward the\u00a0<strong>\u201cAI Risk Assessment Transaction\u201d<\/strong>\u00a0metric.\u00a0<strong>In the IdP&#8217;s charging model design for SPs, this metric is priced higher than a basic MFA transaction.<\/strong><\/li>\n\n\n\n<li>Finally,\u00a0<strong>Smallsoft Identity<\/strong>\u00a0embeds the final risk decision (e.g.,\u00a0<code>RiskLevel: High<\/code>) as a Claim in the Access Token for use by the SP&#8217;s Policy Enforcement Point (PEP).<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"52-feasibility-and-expected-benefits-of-the-architecture\">5.2 Feasibility and Expected Benefits of the Architecture<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Expected Performance:<\/strong>\u00a0The DEDA architecture is designed to shift metering I\/O to the asynchronous event bus, anticipating maintaining extremely low latency for the core authentication flow and high stability under high concurrency.<\/li>\n\n\n\n<li><strong>Expected Reliability:<\/strong>\u00a0The design ensures high availability, as the Core Identity Service and authentication flow can continue to operate even if the Commercial Metering Service is temporarily unavailable due to maintenance or high load.<\/li>\n\n\n\n<li><strong>Expected Scalability:<\/strong>\u00a0By deploying Metering, Auditing, and Core Identity Services as independent microservice clusters, the platform is expected to allow independent scaling of each component to meet varying business demands.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"6-conclusion-and-future-work\">6. Conclusion and Future Work<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"61-conclusion\">6.1 Conclusion<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The DEDA architecture proposed in this paper, using the&nbsp;<strong>Smallsoft Identity platform<\/strong>&nbsp;as a conceptual design, successfully balances the requirements for security, scalability, and commercialization in a multi-tenant IDaaS environment. By implementing physical and logical decoupling between the core authentication and the commercial metering\/attribute synchronization systems, the design achieves:&nbsp;<strong>strict tenant security isolation, high-precision, multidimensional transaction metering, and minimal dependency on the SP&#8217;s billing system.<\/strong>&nbsp;This architectural model provides a secure and commercially viable blueprint for next-generation IDaaS platforms.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"62-future-work\">6.2 Future Work<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Future research will focus on the following directions:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Federated Authorization Attributes:<\/strong>\u00a0Exploring how to efficiently and securely embed authorization decisions from external authorization services (e.g., OPA &#8211; Open Policy Agent) into the DEDA architecture&#8217;s Claims flow.<\/li>\n\n\n\n<li><strong>Identity Governance Metering:<\/strong>\u00a0Designing and integrating advanced metering metrics for Identity Governance features (e.g., access reviews, lifecycle orchestration) to further expand the commercial value of the IDaaS platform.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"appendix-a-acronyms\">Appendix A: Acronyms<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Acronym<\/th><th class=\"has-text-align-left\" data-align=\"left\">Full English Term<\/th><\/tr><\/thead><tbody><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>DEDA<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">Decoupled, Event-Driven Architecture<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>IdP<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">Identity Provider<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>SP<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">Service Provider (i.e., the IdP&#8217;s Tenant)<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>IDaaS<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">Identity as a Service<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>MAU<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">Monthly Active Users<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>MFA<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">Multi-Factor Authentication<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>OAuth 2.0<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">Open Authorization 2.0<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>OIDC<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">OpenID Connect<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>SCIM<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">System for Cross-domain Identity Management<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>Claims<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">Claims (Attributes carried in JWT\/Tokens)<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>PEP<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">Policy Enforcement Point<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>DAL<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">Data Access Layer<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>AOP<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">Aspect-Oriented Programming<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>HSM<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">Hardware Security Module<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\"><strong>API<\/strong><\/td><td class=\"has-text-align-left\" data-align=\"left\">Application Programming Interface<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Contact<\/strong>: Geoffrey Chen&nbsp;<a href=\"mailto:me@geoffreychen.com\">me@geoffreychen.com<\/a><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Verified GPG Public Key<\/strong>:&nbsp;<a href=\"https:\/\/keys.openpgp.org\/search?q=me@geoffreychen.com\">https:\/\/keys.openpgp.org\/search?q=me@geoffreychen.com<\/a>&nbsp;(2025.12.15 Australia)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>As Identity as a Service (IDaaS) becomes a critical component of SaaS infrastructure, building a Multi-Tenant Identity Provider (IdP) requires not only meeting stringent security and scalability requirements but also supporting flexible, high-precision monetization models. Traditional IdP architectures face challenges of high coupling and limited scalability when handling fine-grained authorization attributes and high-frequency metering events.<\/p>","protected":false},"author":17897162,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"image","meta":{"_coblocks_attr":"","_coblocks_dimensions":"","_coblocks_responsive_height":"","_coblocks_accordion_ie_support":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":true,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_geoff_meta_description_en":"","_geoff_meta_description_zh":"","_wpcom_ai_launchpad_first_post":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[784633319],"tags":[],"class_list":["post-11629","post","type-post","status-publish","format-image","hentry","category-ai-frontiers","post_format-post-format-image",""],"translatepress_titles":{"en_AU":"Architectural Design for Commercializing Multi-Tenant Identity Platforms While Ensuring Security"},"jetpack_publicize_connections":[],"jetpack_likes_enabled":false,"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p1ar9H-31z","jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/geoffreychen.com\/zh\/wp-json\/wp\/v2\/posts\/11629","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/geoffreychen.com\/zh\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/geoffreychen.com\/zh\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/geoffreychen.com\/zh\/wp-json\/wp\/v2\/users\/17897162"}],"replies":[{"embeddable":true,"href":"https:\/\/geoffreychen.com\/zh\/wp-json\/wp\/v2\/comments?post=11629"}],"version-history":[{"count":3,"href":"https:\/\/geoffreychen.com\/zh\/wp-json\/wp\/v2\/posts\/11629\/revisions"}],"predecessor-version":[{"id":11632,"href":"https:\/\/geoffreychen.com\/zh\/wp-json\/wp\/v2\/posts\/11629\/revisions\/11632"}],"wp:attachment":[{"href":"https:\/\/geoffreychen.com\/zh\/wp-json\/wp\/v2\/media?parent=11629"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/geoffreychen.com\/zh\/wp-json\/wp\/v2\/categories?post=11629"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/geoffreychen.com\/zh\/wp-json\/wp\/v2\/tags?post=11629"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}