Architectural Design for Commercializing Multi-Tenant Identity Platforms While Ensuring Security

Geoffrey Chen

By Geoffrey Chen

Decoupling, Event-Driven, and Minimal Dependence: An Architectural Design for Commercializing Multi-Tenant Identity as a Service (IDaaS) Platforms While Ensuring Security

Abstract

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.

This paper proposes an innovative Decoupled, Event-Driven Architecture (DEDA), using the Smallsoft Identity platform as a design case study. The core of the DEDA architecture lies in the physical and logical decoupling of the high-security-sensitive Core Identity Service from the high-commercial-sensitive Metering Service and Attribute Synchronization Services. This design strictly adheres to TenantId Isolation and the Principle of Least Privilege to ensure security in a multi-tenant environment. It leverages the Identity Event Bus and Fine-Grained Claims 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’s core security boundary or depending on the SP’s end-user billing system, thereby enabling the secure commercialization of IDaaS platforms.

Keywords: Multi-Tenant Identity, IdP Architecture, Commercialization, Metering, Authorization Attributes, OAuth 2.0, OpenID Connect, Microservices.

1. Introduction

1.1 Evolution of Identity Services and Commercialization

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.

This expansion of capabilities imposes a new requirement on IdP architecture: Commercialization. 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.

1.2 Challenges and Necessity

Achieving secure commercialization in an IDaaS platform requires overcoming the following key challenges:

  1. Security Isolation vs. Performance: Ensuring the physical and logical isolation of data and configurations between different SPs, while maintaining low latency and high throughput for the core authentication path.
  2. Billing Dependency Risk: How to provide SPs with accurate billing data (e.g., User A’s 5th MFA transaction this month) while ensuring the IdP does not create a tight coupling or runtime dependency on the SP’s end-user billing system.
  3. Fine-Grained Authorization Data Transfer: A secure, standardized mechanism is necessary to transfer user authorization attributes (e.g., subscription level, quota limits) stored in the IdP to the SP’s application layer, to serve as the basis for SP authorization decisions.

1.3 Contributions

The DEDA architecture model proposed in this paper addresses the above challenges with the following contributions:

  1. Proposal of DEDA Architecture: A microservice-based, event-driven IdP architecture design that decouples high-security authentication from high-commercial-value metering.
  2. Minimal Dependency Input Mechanism: Definition of a dual mechanism—based on the Identity Event Bus and Custom Claims—to enable the IdP to provide billing and authorization input data to the SP with minimal dependency.
  3. Design Case Study: Using the proposed Smallsoft Identity platform design as an example, detailed demonstration of the DEDA architecture’s design for high-value feature metering and business logic decoupling.

2. Limitations of Traditional Architecture and Design Principles

2.1 Issues with Traditional Coupled Architectures

[Content Omitted for Brevity]

2.2 Core DEDA Design Principles

The DEDA architecture adheres strictly to the following principles:

  1. Separation of Concerns: Identity management, metering, and auditing must be independent microservices.
  2. Principle of Least Privilege: Any service (especially the Metering Service) is only granted the minimal privileges required to perform its task.
  3. Eventual Consistency: Minor 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.
  4. Open Standard Communication: Authentication and authorization information transfer must be based on open standards like OAuth 2.0, OpenID Connect, and SCIM.

3. The DEDA Architecture Model: Decoupling and Metering Implementation

The core of the DEDA architecture consists of three independently operating service components communicating via asynchronous messaging: the Core Identity Service, the Identity Event Bus, and the Commercial Metering Service.

3.1 Core Identity Service

The Core Identity Service acts as the IdP’s security boundary. It is responsible for user credential validation, session management, and token issuance.

3.1.1 Implementation of Tenant Isolation

  • Mandatory TenantId Isolation: In the Smallsoft Identity design, all user tables, configuration tables, and audit logs must contain a mandatory TenantId column. Interceptors (e.g., AOP) in the Data Access Layer (DAL) enforce the TenantId filter on all database operations.
  • Resource Isolation: The Smallsoft Identity design proposes providing independent subdomains for each paying tenant (SP) and storing MFA keys and encryption salts in an HSM/Vault partitioned based on TenantId.

3.2 Identity Event Bus

The Identity Event Bus (e.g., using Kafka or similar technologies) serves as the sole data sharing mechanism within the IdP.

  • Real-Time Event Publishing: Whenever a chargeable or auditable key identity event occurs (AUTHN_SUCCESS, MFA_REQUESTED, USER_REGISTERED), the Core Identity Service immediately generates and publishes an event to the bus.
  • Non-Blocking Design: This asynchronous design is crucial for Smallsoft Identity to achieve low authentication latency. The authentication flow is not blocked while waiting for downstream metering service writes.

3.3 Commercial Metering Service

This service focuses exclusively on commercial value capture and is physically and logically separate from the Core Identity Service.

  • Function: It consumes the event stream from the Identity Event Bus to calculate and aggregate the metrics used for the IdP’s billing of SPs.
  • Multidimensional Metering Metrics:The Smallsoft Identity design supports the following metrics:
    • Base Metering: MAU (unique user IDs based on AUTHN_SUCCESS events).
    • High-Value Transaction Metering: Successful MFA transactions, custom policy engine executions.
  • Data Security: The metering database only stores aggregated data (e.g., Tenant A’s MAU count), minimizing the risk of exposure of sensitive user data that could be used for identity restoration.

4. Security and Commercial Input Mechanisms

The DEDA architecture provides the necessary input for SP billing systems through strict interface and data isolation, adhering to the principle of minimal dependency.

4.1 SP Billing Input: Claims-as-Input Mechanism

The Smallsoft Identity design securely transfers authorization attributes via Custom Claims within OAuth 2.0 Access Tokens and OIDC ID Tokens.

  • Custom Claims Design: In the Smallsoft Identity proposal, SPs can pre-define custom Claims to be carried in the token via the management console (e.g., sp_data_quota).
  • Design Case: When User A logs in, the Smallsoft Identity token issuance service retrieves the user’s SubscriptionLevel as "Premium". The token will include the Claim {"SubscriptionLevel": "Premium"}. The SP’s application relies solely on this Claim for authorization. “Premium” is merely an opaque string at the IdP level, serving as an authorization result with no logical meaning; all pricing and feature unlocking logic is executed by the SP, effectively eliminating IdP dependency on the SP’s billing system.

4.2 Real-Time Attribute Synchronization: Application of SCIM Protocol

To ensure the authorization attributes stored in the IdP align with the SP’s commercial source of truth, Smallsoft Identity integrates standard SCIM interfaces.

  • SCIM for Attribute Updates: Smallsoft Identity plans to provide a SCIM Endpoint allowing the SP’s CRM/billing system to send a secure PATCH request to the IdP, updating the user’s attributes (e.g., changing SubscriptionLevel from “Basic” to “Enterprise”).
  • Unidirectional Control: This synchronization is SP-driven; the IdP acts only as an attribute store and distribution point. The SP’s End User Billing system should not have any dependency on the IdP beyond authentication and authorization functionality, making the SCIM interface the only necessary and controlled API dependency.

4.3 Billing Notification: Opening the Identity Event Bus to SPs

Smallsoft Identity plans to offer a Webhook service to forward specific events from the Identity Event Bus to a pre-configured URL for the SP.

  • SP Billing Triggers: SPs can subscribe to USER_REGISTERED events (to start a free trial period) or PROFILE_UPDATED events (to re-evaluate the subscription status). These events carry non-sensitive User ID and Tenant ID. Upon receipt, the SP’s billing backend can immediately trigger its internal logic without requiring additional authentication API calls to the IdP.

5. Design and Case Study

5.1 Design Case: Metering of AI-Enhanced Authentication in Smallsoft Identity

The Smallsoft Identity design incorporates AI-enhanced Adaptive Authentication based on machine learning models.

  • Process: During user login, the Core Identity Service calls a separate AI Risk Assessment Microservice.
  • Events and Metering:
    1. Smallsoft Identity immediately publishes a RISK_SCORE_COMPUTED event after each AI service call. The event payload includes the TenantId and the Score.
    2. The Commercial Metering Service consumes this event and counts the transaction toward the “AI Risk Assessment Transaction” metric. In the IdP’s charging model design for SPs, this metric is priced higher than a basic MFA transaction.
    3. Finally, Smallsoft Identity embeds the final risk decision (e.g., RiskLevel: High) as a Claim in the Access Token for use by the SP’s Policy Enforcement Point (PEP).

5.2 Feasibility and Expected Benefits of the Architecture

  • Expected Performance: The 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.
  • Expected Reliability: The 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.
  • Expected Scalability: By 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.

6. Conclusion and Future Work

6.1 Conclusion

The DEDA architecture proposed in this paper, using the Smallsoft Identity platform 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: strict tenant security isolation, high-precision, multidimensional transaction metering, and minimal dependency on the SP’s billing system. This architectural model provides a secure and commercially viable blueprint for next-generation IDaaS platforms.

6.2 Future Work

Future research will focus on the following directions:

  1. Federated Authorization Attributes: Exploring how to efficiently and securely embed authorization decisions from external authorization services (e.g., OPA – Open Policy Agent) into the DEDA architecture’s Claims flow.
  2. Identity Governance Metering: Designing 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.

Appendix A: Acronyms

AcronymFull English Term
DEDADecoupled, Event-Driven Architecture
IdPIdentity Provider
SPService Provider (i.e., the IdP’s Tenant)
IDaaSIdentity as a Service
MAUMonthly Active Users
MFAMulti-Factor Authentication
OAuth 2.0Open Authorization 2.0
OIDCOpenID Connect
SCIMSystem for Cross-domain Identity Management
ClaimsClaims (Attributes carried in JWT/Tokens)
PEPPolicy Enforcement Point
DALData Access Layer
AOPAspect-Oriented Programming
HSMHardware Security Module
APIApplication Programming Interface

Contact: Geoffrey Chen [email protected]

Verified GPG Public Key: https://keys.openpgp.org/[email protected] (2025.12.15 Australia)

了解 Geoffrey Chen 的更多信息

订阅后即可通过电子邮件收到最新文章。

发表评论