ahmido
bab01f07a9
## 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
83 lines
2.7 KiB
Markdown
83 lines
2.7 KiB
Markdown
# 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
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
vendor/bin/sail artisan test --compact
|
|
``` |