How to design best Auth methods for Multi Tenant Application?

Below is a proposed design and strategy that addresses your multi-tenant, multi-org environment at Wizbrand while integrating single-tenant open source applications with their own independent RBAC.

1. Centralized Identity Provider & Single Sign-On (SSO)

Objective:
Have one “source of truth” for all users at the Wizbrand level so that when an organization is onboarded and new users are created, they are authenticated centrally. This central system will then federate identities to all integrated applications.

How to Achieve It:

• Implement a Central IDP:
  Deploy a centralized Identity Provider (IDP) (e.g., Keycloak, Auth0, Okta, or even an open-source SAML/OIDC solution) that handles authentication and issues tokens (usually JWTs or SAML assertions).
• Use Standard Protocols:
  Leverage industry-standard protocols such as SAML 2.0 or OpenID Connect (OIDC). These are language-agnostic and widely supported, which means that even if your integrated applications are single tenant, they can be modified (or wrapped) to accept federated logins.

Benefits:

• Unified Login: Users log in once at Wizbrand, and that session is trusted across all services.
• Central User Store: All users, roles, and tenant/organization data are managed centrally.
• Federation: Integrated applications don’t have to maintain independent user directories if they trust the central IDP.

2. Bridging Multi-Tenant to Single-Tenant Applications

Challenge:
Your integrated open source applications are designed as single-tenant systems with their own independent RBAC. This means they expect a local user store and authentication mechanism. Yet, you want them to automatically recognize users added at the Wizbrand org level.

Proposed Solutions:

A. Federated Authentication with Adaptors

• SSO Adapters/Connectors:
  Modify (or wrap) each integrated application to support federated authentication. This means:

  • When a user attempts to access an integrated app, the app redirects (or validates) the authentication token issued by the central IDP.
  • The integrated app maps the identity from the token to its local context.

• Local Account Mapping:
  Even if the integrated application remains single tenant, a middleware layer (or an adapter) can:

  • Check if the user exists in the local store.
  • If not, automatically create a local account using data from the central IDP token (e.g., email, name, tenant/organization ID, and roles).
  • Map Wizbrand roles to the integrated application’s RBAC roles through a pre-defined configuration or mapping table.

B. User Provisioning via SCIM or Custom Sync Mechanism

• SCIM (System for Cross-domain Identity Management):
  If the integrated applications support SCIM or can be extended to support it, use SCIM to automatically provision, update, and de-provision user accounts.

• Custom Sync API:
  Alternatively, implement a background service or webhook mechanism that triggers whenever a user is added/updated in Wizbrand:

  • This service calls the integrated applications’ APIs to create or update user records.
  • The mapping should consider both the tenant context (so that the application “knows” which org the user belongs to) and the roles (admin, manager, user).

Key Considerations:

• Role Mapping:
  Since each integrated app may have its own set of roles, establish a role mapping matrix that converts Wizbrand’s roles into roles recognized by the integrated app. For instance, a Wizbrand “org admin” might map to an “administrator” in the open source application.
• Tenant Isolation:
  Ensure that each integrated application is aware of the tenant context. If the open source app is truly single tenant, you may have to “simulate” multi-tenancy by adding a tenant ID field and filtering data based on that.

3. Workflow Example

1. User Onboarding at Wizbrand Org Level:

   • The org admin adds a new user in Wizbrand.
   • The central IDP creates a new user record that includes organization (tenant) and role information.

2. User Provisioning/Synchronization:

   • Option A: A sync service (using SCIM or a custom API) propagates the new user information to each integrated application, creating a corresponding user account and mapping the appropriate roles.
   • Option B: When the new user logs into an integrated application for the first time via SSO, the application (through its SSO adapter) automatically checks for a corresponding local account. If none exists, it creates one using the token claims.

3. User Navigation & SSO:

   • The user logs into Wizbrand once.
   • The central IDP issues an SSO token (JWT or SAML) that includes the organization and role claims.
   • When the user navigates to an integrated application:
     • The application validates the token.
     • The SSO adapter in the integrated application checks local RBAC mappings.
     • The user is granted access as per their mapped role.

4. Role Management & Updates:

   • Changes in user roles (by the org admin) are updated centrally.
   • The sync mechanism pushes these updates to the integrated applications, ensuring that permissions remain in sync.

4. Implementation Strategy & Tools

Central Identity Management:

• IDP Solutions:

  • Keycloak: Open source, supports multi-tenancy and OIDC/SAML.
  • Auth0 / Okta: Cloud-based, enterprise-ready solutions.

• Protocols:

  • OIDC / SAML 2.0: For federated authentication and SSO.

User Provisioning & Sync:

• SCIM:

  • Use SCIM if the integrated apps support it, or implement a SCIM-compatible endpoint.

• Custom API/Webhook:

  • Develop a middleware service that listens to user creation/updates at Wizbrand and calls the integrated application’s API to sync users.

SSO Integration for Integrated Apps:

• Adapters/Middleware:
  • Develop lightweight adapters for each integrated application that can validate the SSO token, map the token’s claims to the local RBAC, and auto-provision local user accounts.
  • If the integrated applications are built using popular frameworks, use available libraries to handle OIDC/SAML. For example:
  • Node.js: Passport.js with OIDC strategy.
  • Python: python-social-auth or flask-oidc.
  • Java: Spring Security with OIDC support.
  • PHP: SimpleSAMLphp or similar libraries.

Role Mapping:

• Maintain a configuration (possibly in a database or configuration file) that defines how Wizbrand roles translate to each integrated application’s roles.
• Include tenant-specific rules if different organizations require different mappings.

5. Summary Recommendations

• Centralize Authentication:
  Use a centralized IDP to handle authentication across your multi-tenant Wizbrand platform.
• Leverage Federated SSO:
  Integrate SSO via OIDC/SAML for both Wizbrand and each integrated open source application.
• Implement User Provisioning:
  Use SCIM or a custom synchronization mechanism to automatically create/update user accounts in integrated applications as new users are onboarded at Wizbrand.
• Role Mapping & Tenant Awareness:
  Ensure that every token includes tenant and role claims and that integrated applications map these claims to their own RBAC settings.
• Develop Adapters:
  For applications that cannot be easily modified to support federated authentication, create middleware adapters that perform token validation and user provisioning on the fly.

By adopting this design, you can ensure that a user added at the Wizbrand org level is seamlessly and securely propagated to all integrated applications, while still respecting the independent RBAC systems of each application. This unified approach will greatly simplify user management and improve the overall user experience across your digital assets management ecosystem.

Feel free to ask for further details or clarifications on any part of this design!