5.6 KiB
Research — Intune RBAC Baseline Compare & Findings v1
Decision: Add explicit baseline-compare support metadata on foundation types
Rationale: BaselineProfileResource::foundationTypeOptions() currently lists all foundation types from InventoryPolicyTypeMeta::foundations(), which would make every configured foundation implicitly selectable for baseline compare. The spec requires intentional, type-level baseline eligibility metadata so only intuneRoleDefinition becomes eligible and intuneRoleAssignment stays excluded.
Alternatives considered:
- Filter foundation options with hard-coded type checks in Filament resource code: rejected because it hides eligibility rules in UI code and does not create a reusable source of truth.
- Treat every foundation as baseline-eligible by default: rejected because the spec explicitly disallows broad foundation rollout.
Decision: Reuse the existing RBAC Graph contracts and inventory/version evidence from Spec 127
Rationale: config/graph_contracts.php already contains inventory-grade contracts for intuneRoleDefinition and intuneRoleAssignment, and Spec 127 already established tenant-scoped inventory plus immutable PolicyVersion evidence for Role Definitions. The compare feature can therefore stay DB-first and does not need new live Graph calls for baseline rendering or run detail.
Alternatives considered:
- Add new RBAC-specific Graph contracts for compare: rejected because current contracts already include the fields needed for normalized Role Definition diffs.
- Re-hydrate live Graph payloads during compare: rejected because it would violate the existing DB-first compare and monitoring model and introduce misleading drift when live state is unavailable.
Decision: Use Role Definition ID as the compare identity for this foundation type
Rationale: Current baseline capture and compare use display-name-derived BaselineSubjectKey matching. That is adequate for some policy surfaces but does not meet the spec requirement for Role Definition identity, where a delete-and-recreate with a new ID is meaningful drift. The capture and compare pipeline needs a targeted identity-model extension for intuneRoleDefinition so baseline items and current inventory match by stable external ID.
Alternatives considered:
- Keep display-name matching and treat renamed duplicates as ambiguous: rejected because it would hide recreated roles and violate the spec’s identity model.
- Match by a composite of display name plus built-in/custom state: rejected because the object identity still changes when a role is recreated.
Decision: Reuse IntuneRoleDefinitionNormalizer::flattenForDiff() as the normalized compare surface
Rationale: The existing normalizer already produces deterministic, order-insensitive permission-block output and readable summary blocks for Role Definitions. Reusing that normalization path keeps diff semantics aligned with the inventory and version-display model from Spec 127 and avoids a second RBAC diff representation.
Alternatives considered:
- Hash raw snapshot payloads directly: rejected because transport noise and ordering differences would create unstable findings.
- Build a separate RBAC-only diff normalizer: rejected because the existing normalizer already captures the governance-relevant fields required by the spec.
Decision: Keep unified baseline.compare finding lifecycle and recurrence behavior
Rationale: CompareBaselineToTenantJob::upsertFindings() already provides profile-scoped recurrence keys, idempotent times_seen updates, reopen behavior, and baseline auto-close support. The RBAC feature should plug into that same lifecycle so findings behave consistently with the rest of the drift engine.
Alternatives considered:
- Introduce an RBAC-specific finding table or source lifecycle: rejected because it would duplicate the compare engine and break existing findings surfaces.
- Make recurrence snapshot-scoped for RBAC only: rejected because the current implementation and tests are profile-scoped, and the new spec only requires baseline profile participation in the fingerprint inputs.
Decision: Extend the existing evidence contract instead of inventing an RBAC-only UI model
Rationale: Existing baseline compare evidence already carries summary kind, provenance, baseline and current version references, and diff-compatible structures consumed by findings and run-detail surfaces. RBAC compare should extend those contracts with an RBAC-specific summary kind and before/after normalized evidence so existing UI surfaces can render the new findings without a dedicated page.
Alternatives considered:
- Render RBAC changes from ad-hoc JSON blobs in the UI: rejected because it would bypass the unified finding evidence contract and create fragile presentation logic.
- Create a new RBAC findings screen: rejected because the spec explicitly requires compatibility with existing baseline, drift, and findings surfaces.
Decision: Reuse existing coverage-guard and partial-success semantics for RBAC safe degradation
Rationale: CompareBaselineToTenantJob already suppresses findings for uncovered types and records partial-success outcomes with coverage reason codes. RBAC compare should use the same mechanism so missing provider or permission coverage produces a clear run/report warning without emitting false drift.
Alternatives considered:
- Emit missing findings when current RBAC data is unavailable: rejected because it would create false drift.
- Fail the entire compare run hard on any RBAC coverage gap: rejected because the current engine already supports safer partial-success semantics with explicit suppression reasons.