...
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 an investigation into Keycloak performance issues, we identified a critical limitation was identified:
When a module is entitled to only a single consortium member, the system user is created solely for that member tenant.
However, when If the same module (, entitled to a specific data tenant) , attempts to interact with another data tenant or the central tenant via through cross-tenant requests, it requires a system user that must already exist in the target data tenant.
The system user is created System users are generated during the entitlement process for a specific tenant. If the a module is not entitled across all member tenants and the consortium’s central tenant in the consortium, it fails to cannot interact with other tenants, causing resulting in exceptions in the sidecar.
...
Problem Statement
Scenario: Mod Request-Mediated Flow
Modules are split into smaller applications, each consisting of comprising a single backend and frontend module designed to display the UI.
...
Proposed Solutions
...
Tactical Solutions:
Deploy the module across all consortium tenants in the consortium.
Pros:
No changes required needed in the existing logic or code.
Cons:
The UI will display unnecessary capabilities and capability sets, exposing irrelevant application interfaces to end-users.
Separate the UI and backend modules.
Pros:
Requires minimal changes—just adjusting Minimal changes required—adjust applications to move isolate the backend module into in a complete standalone application.
Cons:
End-users will not see the UI components or associated capability setscapabilities, but backend capabilities may still be unexpectedly unintentionally assigned.
Long-Term Solution:
Introduce a new application status: Enable/Disable Proof of Concepts for Workarounds:
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.
...
Strategic Solutions:
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.
| Drawio | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
This ensures system users are consistently created for all tenants in the consortium.
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
...
Refactor the UI approach to better handle application visibility.
...
:
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).