Skip to end of banner
Go to start of banner

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

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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 our investigation into Keycloak performance issues, we identified a critical limitation:

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

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

The system user is created during the entitlement process for a specific tenant. If the module is not entitled across all member tenants and the consortium’s central tenant, it fails to interact with other tenants, causing exceptions in the sidecar.

Problem Statement

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

Proposed Solutions

Short-Term Solutions:

  1. Deploy the module across all tenants in the consortium.

    • Pros:

      • No changes required in the existing logic or code.

    • Cons:

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

  2. Separate the UI and backend modules.

    • Pros:

      • Requires minimal changes—just adjusting applications to move the backend module into a complete application.

    • Cons:

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

Long-Term Solution:

  1. Introduce a new application status: Enable/Disable for specific tenants.

    • Steps:

      • Define the meaning and behavior of this status.

      • Ensure capabilities and capability sets for disabled tenants are not returned or displayed.

    • Pros:

      • Provides granular control over module availability and visibility.

      • Prevents unnecessary capabilities from being exposed to tenants.

    • Cons:

      • Requires significant design changes, including how the UI determines which applications and capabilities are displayed for specific tenants.

  2. Refactor the UI approach to better handle application visibility.

    • Adjust the logic for determining what the UI should show or hide based on tenant-specific configurations.

  • No labels