ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects 1 Releases Wiki Activity

spec: 105 clarifications — group counting + capability boundary

Browse Source
This commit is contained in:
Ahmed Darrazi 2026-02-21 23:57:34 +01:00
parent dbb7f1fbab
commit b6e376e875
1 changed files with 7 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
specs/105-entra-admin-roles-evidence-findings/spec.md
View File

@ -20,7 +20,8 @@ ## Spec Scope Fields *(mandatory)*
- `config/entra_permissions.php` — new registry file for Entra-specific Graph permissions (workspace infra)
- **RBAC**:
- Workspace membership required for any access (non-members → 404)
- New capabilities: `ENTRA_ROLES_VIEW` (see report, see findings), `ENTRA_ROLES_MANAGE` (trigger on-demand scan)
- New capabilities: `ENTRA_ROLES_VIEW` (see Admin Roles card + report viewer), `ENTRA_ROLES_MANAGE` (trigger on-demand scan)
- `entra_admin_roles` findings in the Findings list are gated by existing `FINDINGS_VIEW` — `ENTRA_ROLES_VIEW` is NOT required to see them
- Readonly/Operator roles → `ENTRA_ROLES_VIEW`
- Manager/Owner roles → `ENTRA_ROLES_MANAGE`
- Findings remain gated by existing `TENANT_FINDINGS_ACKNOWLEDGE` for acknowledge actions
@ -142,6 +143,7 @@ ### Edge Cases
- **Graph API returns partial data**: If `roleDefinitions` succeeds but `roleAssignments` fails (or vice versa), the scan MUST fail the OperationRun (no partial reports). All-or-nothing per scan.
- **Service principal assignments**: Some high-privilege role assignments go to service principals, not users. The finding generator MUST handle all principal types (`user`, `group`, `servicePrincipal`) and include the principal type in evidence.
- **Group-assigned roles**: When a group holds a high-privilege role, it counts as one principal (no member expansion in v1). The finding is created for the group itself. The aggregate "Too many Global Admins" threshold counts assignment records, not expanded members. Evidence records `principal.type=group` so operators can identify group-based assignments for manual review.
- **Scoped role assignments**: Some role assignments are scoped to administrative units (`directory_scope_id != "/"`). The high-privilege finding still applies — scope is recorded in evidence but does not downgrade severity in v1.
- **Role definitions without `template_id`**: Custom role definitions may not have a `template_id`. The `HighPrivilegeRoleCatalog` falls back to `display_name` matching for classification. If neither matches, the role is not flagged as high-privilege.
- **Tenant with zero role assignments**: Possible for app-only tenants. The scan produces a valid report with `assignments_total=0` and no findings.
@ -161,8 +163,8 @@ ## Requirements *(mandatory)*
**Constitution alignment (RBAC-UX):**
- **Authorization planes**: Tenant-context (`/admin/t/{tenant}/...`) for viewing reports and findings; workspace-context for alerts.
- **404 vs 403**: Non-member / not entitled to workspace or tenant scope → 404 (deny-as-not-found). Member missing `ENTRA_ROLES_VIEW` → 403 for view. Member missing `ENTRA_ROLES_MANAGE` → 403 for scan.
- **Server-side enforcement**: New policy for on-demand scan action; existing `FindingPolicy` covers posture findings.
- **404 vs 403**: Non-member / not entitled to workspace or tenant scope → 404 (deny-as-not-found). Member missing `ENTRA_ROLES_VIEW` → 403 for Admin Roles card/report. Member missing `ENTRA_ROLES_MANAGE` → 403 for scan. Findings list uses existing `FINDINGS_VIEW` (no `ENTRA_ROLES_VIEW` required).
- **Server-side enforcement**: New policy for on-demand scan action; existing `FindingPolicy` covers findings (gated by `FINDINGS_VIEW`, not `ENTRA_ROLES_VIEW`).
- **Capability registry**: New constants `ENTRA_ROLES_VIEW` and `ENTRA_ROLES_MANAGE` added to `App\Support\Auth\Capabilities`.
- **Global search**: No new globally searchable resources.
- **Destructive actions**: None. Scans are read-only; findings are system-generated.
@ -331,6 +333,8 @@ ### Session 2026-02-21
- Q: Is `$expand=principal` reliable for all principal types? → A: Yes — Graph returns principal details for users, groups, and service principals. If expansion fails for a specific principal, the assignment is still recorded with `principal.display_name = null` (evidence captures this gap).
- Q: Why two capabilities (VIEW/MANAGE) instead of reusing existing findings capabilities? → A: The scan action is domain-specific (Entra roles) and should be independently gatable. Viewing the resulting findings still uses existing findings capabilities, but triggering the scan and viewing the admin roles report card uses the new capabilities.
- Q: How is daily scheduling implemented? → A: Same pattern as existing scheduled scans — workspace dispatcher iterates tenants with active connections and dispatches `ScanEntraAdminRolesJob` per tenant.
- Q: When a group is assigned a high-privilege role, does the finding generator expand group members or treat the group as one principal? → A: Group = 1 principal. No member expansion in v1. Findings and the aggregate GA threshold count reflect Graph roleAssignment records directly (1 assignment = 1 finding). Member expansion would require additional Graph calls + `GroupMember.Read.All` permission and is deferred to a future spec.
- Q: Should `ENTRA_ROLES_VIEW` gate `entra_admin_roles` findings in the Findings list too, or only the Admin Roles card + report viewer? → A: Card + report only. `ENTRA_ROLES_VIEW` gates the Admin Roles dashboard card and the stored-report viewer. Findings of type `entra_admin_roles` in the Findings list remain gated by the existing `FINDINGS_VIEW` capability (no dual-gate).
## Success Criteria *(mandatory)*