From d991ae152b0928f668267bac99e2d74d26d3ca50 Mon Sep 17 00:00:00 2001 From: "angelica.puddu" Date: Wed, 5 Aug 2026 20:22:29 +0200 Subject: [PATCH] Backport RBAC FAQ and Console tenant isolation note to v15.0.0 docs Applies the same additions made to the current docs to the published v15.0.0 versioned docs, so the live site reflects them. --- .../mia-platform-suite/rbac_management.md | 39 +++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/versioned_docs/version-15.0.0/products/mia-platform-suite/rbac_management.md b/versioned_docs/version-15.0.0/products/mia-platform-suite/rbac_management.md index 5b9b08e9b8..c7b0890223 100644 --- a/versioned_docs/version-15.0.0/products/mia-platform-suite/rbac_management.md +++ b/versioned_docs/version-15.0.0/products/mia-platform-suite/rbac_management.md @@ -22,6 +22,7 @@ Mia-Platform's RBAC system is a centralized service designed for granular access - **Input schema** — a JSON Schema file in the *schemas/* directory that defines the structure of *input.rbac*, used for validating and type-checking policy inputs. - **Super Admin** — a global administrative role (*...authz:Super Admin*) with full privileges to manage the entire platform. - **Organization Admin** — an administrative role (*...organization-Super Admin:\*) with full privileges limited to a specific organization. +- **Keycloak Admin** — an identity-management role, distinct from Super Admin/Organization Admin, that manages users at the organization level directly from the organization's dedicated Keycloak console (e.g., adding or removing users from the organization). - **Scope** — defines the extent of a permission: it can be global ('/') or restricted to a specific path (e.g., */\*). - **Decision helper** — a function (*helpers.decision(input)* in *authz/helpers/acl_context.rego*) that evaluates policies and generates the final decision, attaching the *x-mia-acl-context* header. - **Allowed resource actions** — a list of URN permissions assigned to a principal's role within *input.rbac.roles[]*. @@ -51,6 +52,8 @@ Below is the specific behavior for each product. For Console, roles and permissions are chosen from a **fixed, predefined list**, they cannot be customized or extended. Admins can assign these predefined roles to users, service accounts, or groups. +Console tenants and the tenants of the new products do not interact with each other: they are managed independently, and RBAC roles assigned in one cannot be managed from the Administration page of the other. + See organization's detail at [Manage users](/products/console/identity-and-access-management/manage-users.md). ### AI Foundry @@ -234,6 +237,42 @@ From the api-portal, call `POST /api/service-accounts/register`, providing the s To remove a service account later, call `DELETE /api/service-accounts/{client_id}` the same way. +## Frequently asked questions + +### Who is the Organization Admin and how is this role acquired? + +- **PaaS**: the Super Admin is designated via Keycloak (during installation but also afterwards). Organization Admin permissions can instead be assigned at a later stage via the front-end, from the Administration panel, but only after the organization has already been created. +- **On-Premise**: the Super Admin is appointed at the creation of the organization in Keycloak. Only one organization is possible, so the Super Admin and the Organization Admin roles coincide. + +### How and where are tenants managed? + +Currently, tenant management (creation and modification, but not deletion) occurs via the API Portal, and only Super Admins and Org Admins can perform these actions. + +### How are new users added, and who is authorized to do so? + +- **Keycloak Admin** — adds users to the organization (via their personal Keycloak console). +- **Org Admin** — adds users to a tenant (via API Portal). + +### Is it possible to add users, groups, or roles in "bulk" mode to speed up onboarding? + +At the moment, bulk user addition is not supported. + +### How does the user offboarding procedure work? + +From the interface, the Organization Admin can delete a user directly from the user management page in the organization's dedicated Keycloak instance. + +### How does combined permission assignment work when a user belongs to multiple groups? + +A user's effective permissions are the union of all roles granted by each group they belong to. For example, if a user belongs to Group A (with Role X) and Group B (with Role Y), they will have both Role X and Role Y — see the [practical example of Alice Parker](#practical-example-of-granularity-and-access-management) above. Role assignment follows a deny-by-default model, meaning permissions must be explicitly granted: nothing is accessible by default. + +### How is a service account registered? + +It cannot be created from the Administration interface. A Super Admin must call the dedicated API — see [Registering a service account](#registering-a-service-account) above. + +### Tenants of new products vs. Console: what is the difference, and how do they interact? + +Currently, tenants from new products and Console tenants do not interact with each other. The same limitation applies to RBAC roles: they cannot be managed from the Administration page on the home page for one from the other. See [Accessing the Administration section](#accessing-the-administration-section) above for more details. + ## Advantages of adoption The integration of RBAC ensures high standards of security and efficiency: