/
EUREKA-623 - Investigate cross-tenant query requests for modules that are not entitled across all tenants in the consortium.

EUREKA-623 - Investigate cross-tenant query requests for modules that are not entitled across all tenants in the consortium.

Owned by Viktor Gema
Last updated: about 6 hours ago
2 min read

WORK IN PROGRESS

Spike Overview

Jira Ticket: EUREKA-623

Objective:
Investigate cross-tenant query requests for modules that are not entitled across all tenants within the consortium.

Background

During an investigation into Keycloak performance issues, a critical limitation was identified:

  • When a module is entitled to only a single consortium member, the system user is created solely for that tenant.

  • If the same module, entitled to a specific data tenant, attempts to interact with another data tenant or the central tenant through cross-tenant requests, it requires a system user that must already exist in the target data tenant.

System users are generated during the entitlement process for a specific tenant. If a module is not entitled across all member tenants and the central tenant in the consortium, it cannot interact with other tenants, resulting in exceptions in the sidecar.

Problem Statement

Scenario: Mod Request-Mediated Flow
Modules are split into smaller applications, each comprising a single backend and frontend module designed to display the UI.

Proposed Solutions

Short-Term Solutions:

  1. Deploy the module across all consortium tenants.

    • Pros:

      • No changes needed in the existing logic or code.

    • Cons:

      • The UI will display unnecessary capabilities and capability sets, exposing irrelevant interfaces to end-users.

  2. Separate the UI and backend modules.

    • Pros:

      • Minimal changes required—adjust applications to isolate the backend module in a standalone application.

    • Cons:

      • End-users will not see the UI components or associated capabilities, but backend capabilities may still be unintentionally assigned.

  3. Proof of Concepts for Workarounds:

    • EUREKA-631:

      • Enable app-tier logic for all tenants, ensuring system users are created. Then, disable the application for data tenants without purging (purge=false). This ensures system users exist while disabling the application for data tenants.

      • Experiment with enabling only the backend module for all tenants, excluding the UI module. This has been partially explored by the Vega team.

Long-Term Solutions:

  1. Introduce Reconciliation Logic for System Users:

    • Ensure all system users exist across all consortium tenants by implementing reconciliation functionality triggered in scenarios such as:

      • When a new tenant is added to the consortium.

      • When a tenant is removed from the consortium.

      • When a tenant is updated within the consortium.

     

This ensures system users are consistently created for all tenants in the consortium.

  1. Introduce a New Application Status:

    • Define an "Enable/Disable" status for specific tenants.

    • Steps:

      • Establish the meaning and behavior of this status.

      • Ensure capabilities and capability sets for disabled tenants are excluded from REST endpoints.

    Pros:

    • Offers granular control over module visibility and availability.

    • Prevents unnecessary capabilities from being exposed to tenants.

    Cons:

    • Requires significant design changes, including:

      • Adjustments to mod-role-keycloak and mod-users-keycloak for managing tenant-specific application entitlements.

      • Defining logic for application entitlement steps (e.g., creating necessary Keycloak resources but marking them as disabled or handling logic on the module side when the UI interacts with it).