TenantAtlas/specs/137-platform-provider-identity/quickstart.md
ahmido bab01f07a9 feat: standardize platform provider identity (#166)
## Summary
- standardize Microsoft provider connections around explicit platform vs dedicated identity modes
- centralize admin-consent URL and runtime identity resolution so platform flows no longer fall back to tenant-local credentials
- add migration classification, richer consent and verification state handling, dedicated override management, and focused regression coverage

## Validation
- focused repo test coverage was added across provider identity, onboarding, audit, policy, guard, and migration flows
- latest explicit passing run in the workspace: `vendor/bin/sail artisan test --compact tests/Feature/AdminConsentCallbackTest.php tests/Feature/Audit/ProviderConnectionConsentAuditTest.php`

## Notes
- branch includes the full Spec 137 artifact set under `specs/137-platform-provider-identity/`
- target base branch: `dev`

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #166
2026-03-13 16:29:08 +00:00

2.7 KiB

Quickstart: Platform Provider Identity Standardization

Purpose

Validate the platform-default Microsoft provider flow, the dedicated override flow, and the legacy classification safeguards after implementation.

Prerequisites

  1. Sail services are running.
  2. The central Graph platform identity is configured in environment or secret-backed config.
  3. A workspace owner or similarly authorized user exists.

Environment Setup

vendor/bin/sail up -d
vendor/bin/sail artisan migrate --no-interaction

Deployment sequencing rule:

  • Run schema migrations first.
  • Execute legacy classification only after deploy through the explicit classification command or equivalent queued operational path.
  • Do not embed classification or backfill behavior inside schema migrations.

Scenario 1: Standard platform onboarding

  1. Open the managed tenant onboarding wizard or provider connection create flow for a tenant.
  2. Start a new Microsoft connection.
  3. Confirm the form shows the platform app ID read-only and does not ask for client ID or client secret.
  4. Trigger Grant admin consent.
  5. Complete the callback.
  6. Run verification.

Expected outcome:

  • A provider_connections row exists with connection_type=platform.
  • No provider_credentials row is required.
  • Consent and verification are visible separately.

Scenario 2: Dedicated override

  1. Sign in as a user who has the dedicated-management capability.
  2. Open the advanced provider connection management path.
  3. Enable dedicated mode explicitly.
  4. Enter dedicated credential details.
  5. Trigger consent and then verification.

Expected outcome:

  • The connection remains explicitly marked dedicated.
  • A provider_credentials row exists with dedicated metadata.
  • Runtime uses the dedicated identity only.

Scenario 3: Legacy migration classification

  1. Seed or identify one platform-like connection, one true dedicated connection, and one hybrid contradictory connection.
  2. Run the explicit post-deploy migration classifier path.
  3. Inspect the resulting connection metadata and audit logs.

Expected outcome:

  • Platform-like record is classified as platform.
  • Dedicated record is classified as dedicated.
  • Hybrid record is marked review-required and not silently auto-converted.

Focused Test Commands

Run the minimum relevant suites first:

vendor/bin/sail artisan test --compact tests/Unit/Providers
vendor/bin/sail artisan test --compact tests/Feature/Onboarding
vendor/bin/sail artisan test --compact tests/Feature/ProviderConnections
vendor/bin/sail artisan test --compact tests/Feature/Guards
vendor/bin/sail bin pint --dirty --format agent

If those pass and broader confidence is needed:

vendor/bin/sail artisan test --compact