diff --git a/docs/CONFIGURATION.md b/docs/CONFIGURATION.md index a265ecec6..16b74b383 100644 --- a/docs/CONFIGURATION.md +++ b/docs/CONFIGURATION.md @@ -111,7 +111,7 @@ Environment overrides (lock the corresponding UI fields): | `OIDC_ALLOWED_GROUPS` | Allowed groups (space or comma-separated) | | `OIDC_ALLOWED_DOMAINS` | Allowed email domains (space or comma-separated) | | `OIDC_ALLOWED_EMAILS` | Allowed emails (space or comma-separated) | -| `OIDC_GROUP_ROLE_MAPPINGS` | Comma-separated group=role mappings (Pro/legacy Pro+/Cloud) | +| `OIDC_GROUP_ROLE_MAPPINGS` | Comma-separated group=role mappings (built-in roles on every plan; custom-role administration requires Pro RBAC) | | `OIDC_CA_BUNDLE` | Custom CA bundle path | diff --git a/docs/OIDC.md b/docs/OIDC.md index 31ad2d1f0..75d89c286 100644 --- a/docs/OIDC.md +++ b/docs/OIDC.md @@ -34,9 +34,9 @@ Restrict access to specific users or groups: - **Allowed Domains**: Restrict to specific email domains (e.g., `example.com`). - **Allowed Emails**: Allow specific email addresses. -### Group-to-Role Mapping (Pro and Above) +### Group-to-Role Mapping -Automatically assign Pulse roles based on OIDC group membership. When a user logs in, Pulse checks their groups claim and assigns the corresponding roles. +Automatically assign Pulse roles based on OIDC group membership. When a user logs in, Pulse checks their groups claim and assigns the corresponding roles. Mapping groups to the built-in `admin`, `operator`, and `viewer` roles is included with Community SSO. Creating custom roles and manually managing user assignments remain Pro RBAC features. **Configuration:** Group-role mappings are configured per SSO provider through the UI (or the @@ -129,7 +129,7 @@ Create the provider in Pulse first (**Settings → Security → Single Sign-On > **Warning — group overage**: if a user belongs to more groups than Entra will fit in a token, Entra omits the `groups` claim entirely and sends a `_claim_names` / `_claim_sources` overage marker pointing at Microsoft Graph instead. Pulse does not follow that marker, so it sees the user as having no groups — and because a configured group-role mapping is authoritative, that login **clears** the user's role assignments instead of leaving them alone. Selecting **Groups assigned to the application** rather than **Security groups** in Token configuration keeps the claim small and avoids the overage. If the token still carries every security group after that, check the app registration **Manifest**: `groupMembershipClaims` must be exactly `"ApplicationGroup"`. A value like `"SecurityGroup, ApplicationGroup"` (left over from an earlier Token configuration choice) keeps emitting all security groups no matter what **Assignment required** is set to, so edit the manifest to drop `SecurityGroup`. -> **Note**: Group-to-role mapping requires a Pro (or above) license. Plain SSO login and **Allowed Groups** gating work on any plan. +> **Note**: Plain SSO login, **Allowed Groups** gating, and group mapping to built-in roles work on every plan. Creating custom roles and manually managing user assignments require Pro RBAC. ## 🔧 Troubleshooting diff --git a/docs/PULSE_PRO.md b/docs/PULSE_PRO.md index e2f901bb0..deb8481b4 100644 --- a/docs/PULSE_PRO.md +++ b/docs/PULSE_PRO.md @@ -143,9 +143,9 @@ This matrix reflects the entitlement keys enforced in code plus the runtime hist | `FeatureKubernetesAI` | `kubernetes_ai` | Kubernetes AI Analysis (Compatibility) | N | N | Y | Y | Legacy compatibility gate for `/api/ai/kubernetes/analyze`; not a primary marketed v6 Pro plan pillar. | | `FeatureAgentProfiles` | `agent_profiles` | Centralized Agent Profiles | N | N | Y | Y | API route gating via `RequireLicenseFeature(..., agent_profiles, ...)`. | | `FeatureUpdateAlerts` | `update_alerts` | Update Alerts (Container/Package Updates) | Y | Y | Y | Y | Included in Community tier per `TierFeatures[TierFree]`. | -| `FeatureSSO` | `sso` | Core SSO (OIDC/SAML) | Y | Y | Y | Y | OIDC and SAML SSO are included in Community tier. | +| `FeatureSSO` | `sso` | Core SSO (OIDC/SAML) | Y | Y | Y | Y | OIDC and SAML SSO, including group mapping to built-in roles, are included in Community tier. | | `FeatureAdvancedSSO` | `advanced_sso` | Multi-Provider SSO | Y | Y | Y | Y | Compatibility capability key; retained for existing entitlement payloads and included in Community to avoid an SSO tax. | -| `FeatureRBAC` | `rbac` | Role-Based Access Control (RBAC) | N | N | Y | Y | API route gating via `RequireLicenseFeature(..., rbac, ...)`. | +| `FeatureRBAC` | `rbac` | Role-Based Access Control (RBAC) | N | N | Y | Y | Custom-role and manual user-assignment administration is gated via `RequireLicenseFeature(..., rbac, ...)`. | | `FeatureAuditLogging` | `audit_logging` | Audit Logging | N | N | Y | Y | API route gating for audit query, verify, and export endpoints. | | `FeatureAdvancedReporting` | `advanced_reporting` | PDF/CSV Reporting | N | N | Y | Y | API route gating via `RequireLicenseFeature(..., advanced_reporting, ...)`. | | `FeatureLongTermMetrics` | `long_term_metrics` | Extended Metric History | N | Y | Y | Y | Runtime history limits are tier-aware through `max_history_days`: Community `7`, Relay `14`, Pro `90`. | diff --git a/docs/RBAC.md b/docs/RBAC.md index 393eba61c..57f680dec 100644 --- a/docs/RBAC.md +++ b/docs/RBAC.md @@ -25,7 +25,7 @@ Users can hold multiple roles. Their effective permissions are combined across a ### OIDC Group Mapping -When using OIDC/SSO, roles can be automatically assigned based on group membership. See [OIDC Group-to-Role Mapping](OIDC.md#group-to-role-mapping-pro-and-above) for configuration. +When using OIDC/SSO, built-in roles can be automatically assigned based on group membership on every plan. See [OIDC Group-to-Role Mapping](OIDC.md#group-to-role-mapping) for configuration. Creating custom roles and manually managing user assignments require Pro RBAC. --- @@ -147,6 +147,8 @@ the upstream IdP account; a later authorized SSO login recreates the record. If you use an OIDC identity provider, Pulse can automatically assign roles based on group membership on each login. +Mapping groups to the built-in `admin`, `operator`, and `viewer` roles is part of Community SSO. Creating custom roles and manually managing user assignments require Pro RBAC. + **UI:** Settings → Security → Single Sign-On → Group Role Mappings **Environment variable** (legacy env-configured OIDC provider only — it does not apply to providers created through the UI or the SSO provider API): @@ -162,7 +164,7 @@ How it works: - Once a provider has any group role mappings configured, the mapping is authoritative: on every login the user's role assignments are replaced with whatever the mapping resolves to. A login that matches no mapped group resolves to an empty set, which clears the user's existing role assignments. Watch for identity providers that silently drop the groups claim (see the Entra ID group overage warning in [OIDC.md](OIDC.md#microsoft-entra-id-formerly-azure-ad)) — to Pulse that looks the same as losing every group. - Role changes are logged to the [audit log](AUDIT_LOGGING.md) as `oidc_role_assignment` events. -See [OIDC documentation](OIDC.md#group-to-role-mapping-pro-and-above) for full configuration details. +See [OIDC documentation](OIDC.md#group-to-role-mapping) for full configuration details. --- diff --git a/frontend-modern/public/docs/CONFIGURATION.md b/frontend-modern/public/docs/CONFIGURATION.md index a265ecec6..16b74b383 100644 --- a/frontend-modern/public/docs/CONFIGURATION.md +++ b/frontend-modern/public/docs/CONFIGURATION.md @@ -111,7 +111,7 @@ Environment overrides (lock the corresponding UI fields): | `OIDC_ALLOWED_GROUPS` | Allowed groups (space or comma-separated) | | `OIDC_ALLOWED_DOMAINS` | Allowed email domains (space or comma-separated) | | `OIDC_ALLOWED_EMAILS` | Allowed emails (space or comma-separated) | -| `OIDC_GROUP_ROLE_MAPPINGS` | Comma-separated group=role mappings (Pro/legacy Pro+/Cloud) | +| `OIDC_GROUP_ROLE_MAPPINGS` | Comma-separated group=role mappings (built-in roles on every plan; custom-role administration requires Pro RBAC) | | `OIDC_CA_BUNDLE` | Custom CA bundle path | diff --git a/frontend-modern/public/docs/OIDC.md b/frontend-modern/public/docs/OIDC.md index 31ad2d1f0..75d89c286 100644 --- a/frontend-modern/public/docs/OIDC.md +++ b/frontend-modern/public/docs/OIDC.md @@ -34,9 +34,9 @@ Restrict access to specific users or groups: - **Allowed Domains**: Restrict to specific email domains (e.g., `example.com`). - **Allowed Emails**: Allow specific email addresses. -### Group-to-Role Mapping (Pro and Above) +### Group-to-Role Mapping -Automatically assign Pulse roles based on OIDC group membership. When a user logs in, Pulse checks their groups claim and assigns the corresponding roles. +Automatically assign Pulse roles based on OIDC group membership. When a user logs in, Pulse checks their groups claim and assigns the corresponding roles. Mapping groups to the built-in `admin`, `operator`, and `viewer` roles is included with Community SSO. Creating custom roles and manually managing user assignments remain Pro RBAC features. **Configuration:** Group-role mappings are configured per SSO provider through the UI (or the @@ -129,7 +129,7 @@ Create the provider in Pulse first (**Settings → Security → Single Sign-On > **Warning — group overage**: if a user belongs to more groups than Entra will fit in a token, Entra omits the `groups` claim entirely and sends a `_claim_names` / `_claim_sources` overage marker pointing at Microsoft Graph instead. Pulse does not follow that marker, so it sees the user as having no groups — and because a configured group-role mapping is authoritative, that login **clears** the user's role assignments instead of leaving them alone. Selecting **Groups assigned to the application** rather than **Security groups** in Token configuration keeps the claim small and avoids the overage. If the token still carries every security group after that, check the app registration **Manifest**: `groupMembershipClaims` must be exactly `"ApplicationGroup"`. A value like `"SecurityGroup, ApplicationGroup"` (left over from an earlier Token configuration choice) keeps emitting all security groups no matter what **Assignment required** is set to, so edit the manifest to drop `SecurityGroup`. -> **Note**: Group-to-role mapping requires a Pro (or above) license. Plain SSO login and **Allowed Groups** gating work on any plan. +> **Note**: Plain SSO login, **Allowed Groups** gating, and group mapping to built-in roles work on every plan. Creating custom roles and manually managing user assignments require Pro RBAC. ## 🔧 Troubleshooting diff --git a/frontend-modern/public/docs/PULSE_PRO.md b/frontend-modern/public/docs/PULSE_PRO.md index e2f901bb0..deb8481b4 100644 --- a/frontend-modern/public/docs/PULSE_PRO.md +++ b/frontend-modern/public/docs/PULSE_PRO.md @@ -143,9 +143,9 @@ This matrix reflects the entitlement keys enforced in code plus the runtime hist | `FeatureKubernetesAI` | `kubernetes_ai` | Kubernetes AI Analysis (Compatibility) | N | N | Y | Y | Legacy compatibility gate for `/api/ai/kubernetes/analyze`; not a primary marketed v6 Pro plan pillar. | | `FeatureAgentProfiles` | `agent_profiles` | Centralized Agent Profiles | N | N | Y | Y | API route gating via `RequireLicenseFeature(..., agent_profiles, ...)`. | | `FeatureUpdateAlerts` | `update_alerts` | Update Alerts (Container/Package Updates) | Y | Y | Y | Y | Included in Community tier per `TierFeatures[TierFree]`. | -| `FeatureSSO` | `sso` | Core SSO (OIDC/SAML) | Y | Y | Y | Y | OIDC and SAML SSO are included in Community tier. | +| `FeatureSSO` | `sso` | Core SSO (OIDC/SAML) | Y | Y | Y | Y | OIDC and SAML SSO, including group mapping to built-in roles, are included in Community tier. | | `FeatureAdvancedSSO` | `advanced_sso` | Multi-Provider SSO | Y | Y | Y | Y | Compatibility capability key; retained for existing entitlement payloads and included in Community to avoid an SSO tax. | -| `FeatureRBAC` | `rbac` | Role-Based Access Control (RBAC) | N | N | Y | Y | API route gating via `RequireLicenseFeature(..., rbac, ...)`. | +| `FeatureRBAC` | `rbac` | Role-Based Access Control (RBAC) | N | N | Y | Y | Custom-role and manual user-assignment administration is gated via `RequireLicenseFeature(..., rbac, ...)`. | | `FeatureAuditLogging` | `audit_logging` | Audit Logging | N | N | Y | Y | API route gating for audit query, verify, and export endpoints. | | `FeatureAdvancedReporting` | `advanced_reporting` | PDF/CSV Reporting | N | N | Y | Y | API route gating via `RequireLicenseFeature(..., advanced_reporting, ...)`. | | `FeatureLongTermMetrics` | `long_term_metrics` | Extended Metric History | N | Y | Y | Y | Runtime history limits are tier-aware through `max_history_days`: Community `7`, Relay `14`, Pro `90`. | diff --git a/frontend-modern/public/docs/RBAC.md b/frontend-modern/public/docs/RBAC.md index 393eba61c..57f680dec 100644 --- a/frontend-modern/public/docs/RBAC.md +++ b/frontend-modern/public/docs/RBAC.md @@ -25,7 +25,7 @@ Users can hold multiple roles. Their effective permissions are combined across a ### OIDC Group Mapping -When using OIDC/SSO, roles can be automatically assigned based on group membership. See [OIDC Group-to-Role Mapping](OIDC.md#group-to-role-mapping-pro-and-above) for configuration. +When using OIDC/SSO, built-in roles can be automatically assigned based on group membership on every plan. See [OIDC Group-to-Role Mapping](OIDC.md#group-to-role-mapping) for configuration. Creating custom roles and manually managing user assignments require Pro RBAC. --- @@ -147,6 +147,8 @@ the upstream IdP account; a later authorized SSO login recreates the record. If you use an OIDC identity provider, Pulse can automatically assign roles based on group membership on each login. +Mapping groups to the built-in `admin`, `operator`, and `viewer` roles is part of Community SSO. Creating custom roles and manually managing user assignments require Pro RBAC. + **UI:** Settings → Security → Single Sign-On → Group Role Mappings **Environment variable** (legacy env-configured OIDC provider only — it does not apply to providers created through the UI or the SSO provider API): @@ -162,7 +164,7 @@ How it works: - Once a provider has any group role mappings configured, the mapping is authoritative: on every login the user's role assignments are replaced with whatever the mapping resolves to. A login that matches no mapped group resolves to an empty set, which clears the user's existing role assignments. Watch for identity providers that silently drop the groups claim (see the Entra ID group overage warning in [OIDC.md](OIDC.md#microsoft-entra-id-formerly-azure-ad)) — to Pulse that looks the same as losing every group. - Role changes are logged to the [audit log](AUDIT_LOGGING.md) as `oidc_role_assignment` events. -See [OIDC documentation](OIDC.md#group-to-role-mapping-pro-and-above) for full configuration details. +See [OIDC documentation](OIDC.md#group-to-role-mapping) for full configuration details. ---