## 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
2.7 KiB
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
- Sail services are running.
- The central Graph platform identity is configured in environment or secret-backed config.
- 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
- Open the managed tenant onboarding wizard or provider connection create flow for a tenant.
- Start a new Microsoft connection.
- Confirm the form shows the platform app ID read-only and does not ask for client ID or client secret.
- Trigger Grant admin consent.
- Complete the callback.
- Run verification.
Expected outcome:
- A
provider_connectionsrow exists withconnection_type=platform. - No
provider_credentialsrow is required. - Consent and verification are visible separately.
Scenario 2: Dedicated override
- Sign in as a user who has the dedicated-management capability.
- Open the advanced provider connection management path.
- Enable dedicated mode explicitly.
- Enter dedicated credential details.
- Trigger consent and then verification.
Expected outcome:
- The connection remains explicitly marked
dedicated. - A
provider_credentialsrow exists with dedicated metadata. - Runtime uses the dedicated identity only.
Scenario 3: Legacy migration classification
- Seed or identify one platform-like connection, one true dedicated connection, and one hybrid contradictory connection.
- Run the explicit post-deploy migration classifier path.
- 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