fix(api): assign fallback role to SAML users (#12223)

docs/user-guide/tutorials/prowler-app-sso-google-workspace.mdx

@@ -2,6 +2,7 @@
 title: 'SAML SSO: Google Workspace'
 ---
 
+import { VersionBadge } from "/snippets/version-badge.mdx"
 import { AppliesTo } from "/snippets/applies-to.mdx"
 
 <AppliesTo />
@@ -113,7 +114,12 @@ The `userType` attribute controls which Prowler role is assigned to the user:
 
 - If `userType` matches an existing Prowler role name, the user receives that role automatically.
 - If `userType` does not match any existing role, Prowler Cloud creates a new role with that name **with read-only access** (visibility over all providers, no management permissions). A Prowler administrator can adjust its permissions afterward through the [RBAC Management](/user-guide/tutorials/prowler-app-rbac) tab.
-- If `userType` is not set, the user's existing roles are left unchanged.
+
+**Fallback Role Without `userType`**
+
+<VersionBadge version="5.37.0" />
+
+If `userType` is not set, the user's existing roles are left unchanged. Users without an existing role in that tenant receive a least-privilege `read_only` fallback role until a Prowler administrator assigns another role. If `read_only` already belongs to a role with different permissions, Prowler Cloud checks suffixed names in order, starting with `read_only_0`. It reuses the first role with the fallback permissions or creates the first available name.
 
 The `userType` value is **case-sensitive** - for example, `Backend` and `backend` are treated as different roles.
 

docs/user-guide/tutorials/prowler-app-sso.mdx

@@ -91,9 +91,15 @@ Choose a Method:
         |----------------|---------------------------------------------------------------------------------------------------------|----------|
         | `firstName`    | The user's first name.                                                                                  | Yes      |
         | `lastName`     | The user's last name.                                                                                   | Yes      |
-        | `userType`     | Determines which Prowler role the user receives (e.g., `admin`, `auditor`). If a role with that name already exists, the user receives it automatically; if it does not exist, Prowler Cloud creates a new role with that name with read-only access (visibility over all providers, no management permissions). If `userType` is not defined, the user's existing roles are left unchanged. Role permissions can be edited in the [RBAC Management tab](/user-guide/tutorials/prowler-app-rbac). | No       |
+        | `userType`     | Determines which Prowler role the user receives (e.g., `admin`, `auditor`). If a role with that name already exists, the user receives it automatically; if it does not exist, Prowler Cloud creates a new role with that name with read-only access (visibility over all providers, no management permissions). A Prowler administrator can adjust its permissions through the [RBAC Management tab](/user-guide/tutorials/prowler-app-rbac). If `userType` is not defined, Prowler Cloud applies the fallback behavior described below. | No       |
         | `organization` | The user's company name.                                                                                | No       |
 
+        **Fallback Role Without `userType`**
+
+        <VersionBadge version="5.37.0" />
+
+        If `userType` is not defined, the user's existing roles are left unchanged. Users without an existing role in that tenant receive a least-privilege `read_only` fallback role. If `read_only` already belongs to a role with different permissions, Prowler Cloud checks suffixed names in order, starting with `read_only_0`. It reuses the first role with the fallback permissions or creates the first available name. A Prowler administrator can then assign the appropriate role through the [RBAC Management tab](/user-guide/tutorials/prowler-app-rbac).
+
         <Info>
         **IdP Attribute Mapping**
 
@@ -163,9 +169,14 @@ Choose a Method:
 
             * If a role with the specified name already exists in Prowler Cloud, the user automatically receives that role.
             * If the role does not exist, Prowler Cloud creates a new role with that exact name with read-only access: the user can see all providers and their findings but cannot manage anything. A Prowler administrator (a user whose role includes the "Manage Account" permission) can adjust its permissions afterward through the [RBAC Management tab](/user-guide/tutorials/prowler-app-rbac).
-            * If `userType` is not defined in the user's Okta profile, the user's existing roles in Prowler Cloud are left unchanged.
             * `userType` must contain a single value. If the IdP sends multiple values, Prowler Cloud uses only the first value and does not assign multiple roles.
 
+            **Fallback Role Without `userType`**
+
+            <VersionBadge version="5.37.0" />
+
+            If `userType` is not defined in the user's Okta profile, the user's existing roles in Prowler Cloud are left unchanged. Users without an existing role in that tenant receive a least-privilege `read_only` fallback role until a Prowler administrator assigns another role. If `read_only` already belongs to a role with different permissions, Prowler Cloud checks suffixed names in order, starting with `read_only_0`. It reuses the first role with the fallback permissions or creates the first available name.
+
             **Example:** To assign the `IT` role to a user, set the `userType` value to `IT` in Okta. If a role named `IT` already exists in Prowler Cloud, the user receives it automatically upon login. If it does not exist, Prowler Cloud creates a new role called `IT` with read-only access, and a Prowler administrator can adjust its permissions as needed.
 
             </Warning>