Description
Authorization-Driven UI Rendering in the Portal
The portal needs the ability to show or hide buttons and UI elements based on user authorization, without requiring something specific for every micro frontend.
To achieve this, the content configuration spec should include a section where UI providers can declare which authorization relations need to be checked. For example, in order to render a given UI, the provider needs to know whether the user is allowed to perform actions X, Y, and Z in the context of resources W, V, and U.
This mechanism must work for both native Kubernetes resources and non-native Kubernetes resources. The content configuration should be generic enough to capture the authorization information needed across all cases.
When all content configurations are aggregated, the portal performs a single batch request to the backend to resolve all authorization checks at once, rather than issuing individual requests per micro frontend.
Out of scope:
Backend does this via SAC in K8s. Doesn't need this.
Objectives
- toggle elements in the ui, give the ui information about specific authorizations the user has.
- gather and pass the informaton to the ui using batch, one request for all information for user
- use context per user and kcp path request
Demo Required
None
Demo Steps
Yes, demo is required with UI (sample)
Description
Authorization-Driven UI Rendering in the Portal
The portal needs the ability to show or hide buttons and UI elements based on user authorization, without requiring something specific for every micro frontend.
To achieve this, the content configuration spec should include a section where UI providers can declare which authorization relations need to be checked. For example, in order to render a given UI, the provider needs to know whether the user is allowed to perform actions X, Y, and Z in the context of resources W, V, and U.
This mechanism must work for both native Kubernetes resources and non-native Kubernetes resources. The content configuration should be generic enough to capture the authorization information needed across all cases.
When all content configurations are aggregated, the portal performs a single batch request to the backend to resolve all authorization checks at once, rather than issuing individual requests per micro frontend.
Out of scope:
Backend does this via SAC in K8s. Doesn't need this.
Objectives
Demo Required
None
Demo Steps
Yes, demo is required with UI (sample)