TenantAtlas/specs/128-rbac-baseline-compare/spec.md

Feature Specification: Intune RBAC Baseline Compare & Findings v1

Feature Branch: feat/128-rbac-baseline-compare
Created: 2026-03-09
Status: Draft
Input: User description: "Spec 128 — Intune RBAC Baseline Compare & Findings v1: Add baseline compare and drift findings for Intune RBAC Role Definitions"

Spec Scope Fields

• Scope: workspace (baseline profile definition + baseline capture) + tenant (baseline compare monitoring and drift findings)
• Primary Routes:
  • Workspace admin: Baseline Profiles create/edit scope, capture baseline, baseline snapshot detail
  • Tenant-context admin: Baseline Compare start/detail, Drift Findings landing/detail, existing baseline result surfaces
• Data Ownership:
  • Workspace-owned: baseline profiles and baseline snapshots, including captured Intune Role Definition version references and evidence-ready baseline metadata
  • Tenant-scoped within a workspace: compare operation runs, compare summaries, and drift findings
  • Existing tenant-owned RBAC inventory and immutable version history remain the current-state evidence source for compare; baseline snapshot items must not persist tenant identifiers
• RBAC:
  • Workspace: workspace_baselines.view to inspect profiles and snapshots; workspace_baselines.manage to edit scope and start baseline capture
  • Tenant: tenant.sync to start compare runs; tenant_findings.view to inspect drift findings and compare result detail
  • Non-members or users outside the active workspace or tenant scope must receive 404 deny-as-not-found behavior; in-scope members missing capability must receive 403

For canonical-view specs: not applicable. This feature extends workspace and tenant surfaces only.

User Scenarios & Testing

User Story 1 - Capture an approved RBAC baseline (Priority: P1)

As a workspace admin, I want to include Intune Role Definitions in a baseline profile and capture them as an approved standard so the tenant's role model can be compared against a known-good baseline later.

Why this priority: Baseline compare has no value until Role Definitions can be deliberately selected and captured as a workspace-owned standard.

Independent Test: Can be fully tested by creating or editing a baseline profile to include Intune Role Definitions, running baseline capture, and verifying that the resulting baseline snapshot stores Role Definition references and excludes Role Assignments.

Acceptance Scenarios:

1. Given a baseline profile whose scope includes Intune Role Definitions, When a workspace admin captures a baseline, Then the baseline snapshot stores Role Definition version references and evidence-ready metadata for the approved set.
2. Given a tenant that also has Intune Role Assignments, When the same baseline capture runs, Then Role Assignments are not added to the baseline snapshot or compare scope.
3. Given a baseline profile that does not include Intune Role Definitions, When a capture runs, Then RBAC Role Definition references are absent from that baseline snapshot.

---

User Story 2 - Detect RBAC drift deterministically (Priority: P1)

As a tenant admin, I want baseline compare to classify Intune Role Definitions as unchanged, modified, missing, or unexpected so I can detect governance drift in the tenant's permission model.

Why this priority: Deterministic compare output is the sellable product outcome for this release and the core reason to extend RBAC beyond inventory/history.

Independent Test: Can be fully tested by comparing a tenant with known Role Definition changes against a captured baseline and verifying classification counts, severity, evidence references, and assignment exclusion.

Acceptance Scenarios:

1. Given a captured baseline and matching current tenant Role Definitions, When a compare run completes successfully, Then the RBAC compare summary reports the items as unchanged and produces no RBAC drift findings.
2. Given a baseline Role Definition whose normalized permissions differ from current state, When compare runs, Then the role is classified as modified and a high-severity RBAC finding is generated.
3. Given a baseline Role Definition that no longer exists in current state, When compare runs with trusted current-state coverage, Then the role is classified as missing and a high-severity RBAC finding is generated.
4. Given a current Role Definition that does not exist in the baseline, When compare runs, Then the role is classified as unexpected and an RBAC finding is generated with deterministic evidence.

---

User Story 3 - Review actionable RBAC findings without assignment noise (Priority: P2)

As a security reviewer, I want RBAC drift to appear in the existing findings and baseline result surfaces with readable evidence and clear labels so I can act on governance changes without manual snapshot diffing or confusion about unsupported assignment drift.

Why this priority: Findings only become operationally useful when they are understandable, correctly labeled, and visibly limited to Role Definitions in this v1.

Independent Test: Can be fully tested by opening RBAC drift findings in the existing findings and run-detail surfaces and verifying labels, before-versus-after evidence, severity, and the absence of assignment compare output or restore affordances.

Acceptance Scenarios:

1. Given a modified Intune Role Definition finding, When a reviewer opens the finding detail or related compare surface, Then the UI clearly labels it as Intune RBAC Role Definition drift and shows readable before-versus-after evidence.
2. Given a metadata-only change to a Role Definition, When compare produces a finding, Then the finding is clearly readable and visibly lower severity than permission changes.
3. Given an RBAC compare run, When a reviewer inspects the summary and findings, Then no Role Assignment objects appear and no UI element implies executable RBAC restore support.

Edge Cases

• A Role Definition deleted and recreated with the same name but a new ID must be treated as meaningful drift: the baseline role becomes missing and the new current role becomes unexpected.
• A metadata-only change such as display name or description must remain visible, but it must not be escalated to the same severity as a permission-set change.
• Built-in versus custom state must remain visible in compare evidence, including the rare case where an unexpected built-in role appears.
• If current-state RBAC data is unavailable or untrusted because provider access, API results, or coverage proof is missing, compare must end with a clear warning or failure state and emit no misleading RBAC drift findings.
• Re-running the same compare against unchanged state must not create duplicate findings or unstable fingerprints.
• Role Assignments must stay absent from baseline selection, capture output, compare summaries, evidence, and findings throughout this release.

Requirements

Constitution alignment (required): This feature extends the existing baseline capture and compare architecture for a new foundation type while remaining read-only from an RBAC governance perspective. It reuses workspace-owned baseline profiles and snapshots, tenant-scoped compare runs, and the unified findings lifecycle. No RBAC write or restore behavior is introduced. Tenant isolation remains mandatory. Existing RBAC inventory and immutable version history from Spec 127 provide the evidence source; compare must not depend on transient UI-time provider calls to render historical evidence.

Constitution alignment (OPS-UX): Baseline capture and compare already use OperationRun, and this feature must remain compliant with the three-surface feedback contract: queued-only toast intent, progress only in active-ops and run-detail surfaces, and a single initiator-only terminal DB notification. OperationRun.status and OperationRun.outcome remain service-owned via OperationRunService. Summary counts remain numeric-only and use canonical keys, while richer RBAC compare counts stay in run context. If a run has no initiator, no terminal DB notification is emitted. Regression coverage must be updated for Role Definition scope expansion, compare outcome semantics, and RBAC-specific summary or warning behavior.

Constitution alignment (RBAC-UX): This feature affects the Tenant/Admin plane and workspace baseline management surfaces only; no Platform-plane behavior changes. Access to baseline profile and snapshot management remains workspace-gated, while compare and findings remain tenant-context gated. Non-members or users outside the active workspace or tenant scope must receive 404 deny-as-not-found responses. In-scope members lacking capability must receive 403. Authorization remains server-side through Gates and Policies backed by the canonical capability registry; no raw capability strings or role-string checks may be introduced. No new global search resource is added, so global search behavior remains unchanged. Existing destructive baseline actions such as archive continue to require confirmation, while this feature introduces no new destructive RBAC action.

Constitution alignment (OPS-EX-AUTH-001): Not applicable beyond the existing rule. This feature does not add auth-handshake behavior and must not introduce any synchronous outbound work on monitoring or findings pages.

Constitution alignment (BADGE-001): Any new or changed severity, coverage, support, or drift-status badges for RBAC compare must stay centralized in existing badge or label mappers. RBAC Role Definition severity and labeling rules must not be implemented as ad-hoc UI mappings; regression tests must cover any new badge or label states.

Constitution alignment (Filament Action Surfaces): Existing Filament baseline and findings screens are extended, so the UI Action Matrix below documents the touched surfaces. The Action Surface Contract remains satisfied because this release adds scope options, summaries, labels, and evidence rendering to existing surfaces without adding a new CRUD resource or destructive row action.

Constitution alignment (UX-001 — Layout & Information Architecture): No new dedicated RBAC screen is introduced. Existing baseline profile forms, compare run detail, and finding detail surfaces retain their established layouts. The feature must fit Role Definition scope selection, compare summaries, labels, and evidence into the existing sectioned forms, lists, and detail views without introducing naked inputs, ambiguous empty states, or table regressions.

Functional Requirements

• FR-128-01 Baseline support declaration: The system must explicitly mark intuneRoleDefinition as baseline-supported in the canonical foundation-type metadata used by baseline profile scope selection.
• FR-128-02 Assignment exclusion declaration: The system must explicitly keep intuneRoleAssignment baseline-unsupported in this release.
• FR-128-03 Baseline profile scope visibility: Workspace admins must be able to include intuneRoleDefinition through the existing baseline profile foundation_types scope selection flow without introducing a separate RBAC-only scope field.
• FR-128-04 Scope clarity: Baseline scope selection must label intuneRoleDefinition as supported for baseline compare in this release and must not offer intuneRoleAssignment as a selectable baseline scope option.
• FR-128-05 Baseline capture inclusion: When a baseline profile includes Intune Role Definitions, baseline capture must include approved Role Definition snapshot or version references in the resulting workspace-owned baseline snapshot.
• FR-128-06 Reference fidelity: Baseline snapshot items for Intune Role Definitions must retain sufficient references and metadata to reconstruct compare evidence later without relying on transient live provider state.
• FR-128-07 Compare participation: Baseline compare must include Intune Role Definitions whenever the active baseline profile scope includes them.
• FR-128-08 Compare exclusion safety: Role Assignments must never participate in RBAC baseline capture, compare summaries, evidence payloads, or findings in this release.
• FR-128-09 Match identity: Compare must match baseline and current Intune Role Definitions by stable tenant-local Role Definition ID.
• FR-128-10 Recreated-role handling: A Role Definition deleted and recreated with a new ID must be treated as material drift rather than silently matched by name.
• FR-128-11 Normalized compare surface: Role Definition compare must operate on normalized governance-relevant content rather than raw transport payloads.
• FR-128-12 Minimum compare dimensions: Normalized compare for Intune Role Definitions must consider display name, description, built-in versus custom state, and normalized permissions content.
• FR-128-13 Ignored noise: Transport-only or otherwise non-material volatile fields must not generate RBAC drift findings.
• FR-128-14 Compare classification: For each in-scope Intune Role Definition, compare must classify the result as unchanged, modified, missing, or unexpected.
• FR-128-15 Modified detection: A Role Definition must be classified as modified when normalized governance-relevant content differs between baseline and current state.
• FR-128-16 Missing detection: A baseline Role Definition absent from trusted current state must be classified as missing.
• FR-128-17 Unexpected detection: A current Role Definition absent from the baseline must be classified as unexpected.
• FR-128-18 Finding generation: Modified, missing, and unexpected Role Definition drift must generate findings through the existing unified findings pipeline using source = baseline.compare semantics.
• FR-128-19 Severity mapping: RBAC Role Definition findings must assign severity consistently according to the approved rules: permission-set change and missing baseline role definition are High, unexpected additional role definition is Medium, and metadata-only change is Low.
• FR-128-20 Evidence payload: RBAC findings must store evidence sufficient for existing drift and finding surfaces to render a readable should-versus-is comparison, including the summary kind, baseline reference, current reference, and normalized before-versus-after evidence shape.
• FR-128-21 Built-in versus custom visibility: Compare summaries and finding evidence must preserve built-in versus custom state so reviewers can interpret RBAC governance impact correctly.
• FR-128-22 Stable fingerprinting: Each RBAC Role Definition drift finding must use a stable fingerprint derived from tenant or provider context, baseline profile, source type intuneRoleDefinition, Role Definition identity, change kind, and normalized diff fingerprint so repeated unchanged drift does not create duplicates.
• FR-128-23 Recurrence behavior: If an RBAC drift condition resolves and later reappears, the existing finding recurrence or reopen behavior must apply without special-case RBAC logic.
• FR-128-24 Compare summary output: Baseline compare result output must include an Intune RBAC Role Definition summary with total compared, unchanged, modified, missing, and unexpected counts.
• FR-128-25 Existing-surface compatibility: RBAC compare summaries, findings, and evidence must render inside existing baseline, drift, and findings surfaces without requiring a new dedicated RBAC resource page.
• FR-128-26 Clear labeling: UI titles, subtitles, and summary text must identify these results as Intune RBAC Role Definition drift rather than generic policy drift.
• FR-128-27 No restore implication: No compare, finding, or detail surface introduced or modified by this release may imply executable RBAC restore support.
• FR-128-28 Scope isolation: Baseline capture, compare, summaries, and findings for Intune Role Definitions must preserve existing workspace and tenant isolation semantics with no cross-tenant leakage.
• FR-128-29 Safe degradation: If required current-state RBAC data is unavailable or untrusted because provider access, API behavior, or permission coverage is insufficient, compare must fail clearly at the run or report level and must not emit misleading RBAC drift findings.
• FR-128-30 Regression safety: Extending baseline compare to Intune Role Definitions must not regress baseline capture, compare, or finding behavior for already supported policy or foundation types.

Non-Goals

• Baseline compare for intuneRoleAssignment
• Drift findings for Role Assignments
• Restore for Intune Role Definitions or Role Assignments
• Cross-tenant compare
• Entra RBAC compare
• New dedicated RBAC resource pages
• Assignment-aware remediation or auto-approval workflows
• Notification routing changes beyond existing finding behavior
• Broad rollout of baseline compare to all remaining foundation types in this release

Assumptions

• Spec 127 already provides stable tenant-scoped Intune Role Definition inventory records, immutable snapshot history, and readable normalized Role Definition output suitable for baseline evidence.
• Existing baseline profile, capture, compare, and findings infrastructure is the single canonical path and should be extended rather than duplicated.
• Role Definition ID is the correct identity anchor for same-tenant governance comparison over time.
• The current release should prefer high-signal governance detection over broader RBAC coverage, which is why Role Assignments remain intentionally excluded.

Dependencies

• Spec 127 Intune RBAC inventory and immutable snapshot history
• Existing baseline capture and compare pipeline
• Existing unified findings lifecycle, recurrence handling, and evidence rendering
• Existing baseline and drift UI surfaces for summaries, findings, and run detail
• Existing tenant and workspace authorization model and capability registry

UI Action Matrix

Surface	Location	Header Actions	Inspect Affordance (List/Table)	Row Actions (max 2 visible)	Bulk Actions (grouped)	Empty-State CTA(s)	View Header Actions	Create/Edit Save+Cancel	Audit log?	Notes / Exemptions
Baseline Profiles	Existing workspace-admin baseline profile screens	Create Baseline Profile	Existing profile inspection affordance remains unchanged	Edit, Archive (confirmed)	None	Existing single empty-state CTA remains	Capture Baseline, Edit, Archive (confirmed)	Save, Cancel	Yes	Scope picker adds Intune Role Definitions as an opt-in supported type and keeps Role Assignments absent. No new destructive action is introduced; archive remains confirmed.
Baseline Snapshot Detail	Existing workspace-admin baseline snapshot/detail surfaces	None new	Existing linked snapshot detail remains unchanged	None new	None	None	Existing detail actions remain	N/A	Yes	Surface adds readable RBAC Role Definition reference context only. No new row or bulk action is introduced.
Baseline Compare Run Detail	Existing tenant-context compare run detail	Run Compare or Re-run Compare where already allowed	Linked from runs list and findings	None new	None	Existing compare CTA remains if no runs exist	None new	N/A	Yes	Adds Intune RBAC Role Definition summary counts, warning states, and evidence links while preserving the existing action surface.
Drift Findings Landing and Detail	Existing tenant-context findings surfaces	None new	Existing table inspection or linked detail remains	Existing view or lifecycle actions remain unchanged	None new	Existing empty-state CTA remains unchanged	Existing detail actions remain	N/A	Yes	Adds RBAC-specific titles, severity mapping, and evidence rendering. No Role Assignment findings appear, and no restore affordance is introduced.

Key Entities

• Baseline Scope Entry: A baseline profile selection that records Intune Role Definitions as an approved compare scope while leaving Role Assignments excluded.
• Baseline Role Definition Reference: The workspace-owned reference inside a baseline snapshot that points to the approved Intune Role Definition version or snapshot evidence used for compare.
• Role Definition Compare Result: The tenant-scoped compare outcome for one Intune Role Definition, including its identity, classification, severity, and readable normalized evidence.
• RBAC Drift Finding: The recurring finding produced when a Role Definition is modified, missing, or unexpected relative to the approved baseline.

Success Criteria

Measurable Outcomes

• SC-128-01 Baseline readiness: A workspace admin can include Intune Role Definitions through the existing baseline profile create-or-edit flow and complete baseline capture successfully without adding Role Assignments to the captured scope.
• SC-128-02 Deterministic compare: For a fixed baseline snapshot and unchanged tenant RBAC state, repeated compare runs produce the same RBAC summary counts and no duplicate findings.
• SC-128-03 Drift detection quality: In verified test scenarios, 100% of Role Definition drift cases are classified into the correct bucket of modified, missing, or unexpected.
• SC-128-04 Severity clarity: In verified test scenarios, permission-set changes and missing baseline roles are always surfaced as High severity, unexpected additional roles as Medium severity, and metadata-only changes as Low severity.
• SC-128-05 Safe trust model: When current-state RBAC evidence is unavailable or untrusted, the compare result warns or fails clearly and emits zero false RBAC drift findings.