QDG Identity: operating and deployment workflow

Document version: 1.0.0. Updated 6 September 2026.

This page describes the current delivery workflow. It does not authorise a production change or claim a completed desktop/Odin proof. The detailed integration procedure for other QDG services will be completed after the first release works.

Stage 1: prove Robert's local connection

Use the separately scoped development Auth0 API and native public client. Finish the eligible login connection, then have Robert sign in through the hosted page. Record the verified issuer/subject and approved actor in protected policy.

Prove the actual Codex desktop flow: discovery, browser login, consent, a permitted read, a permitted synthetic write, rejected stale version, insufficient-scope denial, renewal, client restart and local access removal while an issued token still exists. A CLI authorization request reaching Auth0 is useful diagnostic evidence but does not close the desktop checkpoint.

The local pilot uses bounded synthetic in-memory data and the actual MCP transport. Keep production credentials and content out of the pilot.

Stage 2: collect Odin information once

Use the reviewed Collect-OdinOAuthReadiness.ps1 from the KB MCP repository in elevated 64-bit Windows PowerShell on Odin. The script has fixed KB-only host/path boundaries and writes one new sanitised JSON report.

It collects service state and identity, configuration/artifact hashes, file and directory permissions, runtime evidence, local/effective IIS route findings, the KB listener, read-only database/schema/grant findings and unauthenticated HTTP status observations. It checks for file/ACL/service changes during collection.

Return only the sanitised report and its displayed SHA-256 for review. Keep database configuration, credentials, user policy, raw XML and private backups on Odin. Unknown or skipped checks remain visible rather than becoming assumed defaults.

The collector makes no service, IIS, network, account or database changes. Its only persistent output is the new report.

Stage 3: prepare the host-specific release

Review the report and bind the release plan to the exact host, configuration and artifact hashes. Resolve missing runtime, initial policy or database migration prerequisites before preparing the final execution package. Do not require operators to edit report findings to make them appear verified.

The deployment package must contain the committed application/shared-package artifacts, complete offline dependency lock, exact configuration candidates, reviewed probes, protected probe-input references and current recovery plan. Credentials stay outside the transferable release bundle.

Some facts require evidence beyond the local collector. Public HTTPS does not prove encryption from an external proxy to Odin. Likewise, local IIS log fields do not prove what every other hop records. Service-account effective permissions require review of the collected access rules. These separately reviewed captures must be bound to the same report/host/candidate and have a validity period.

Stage 4: execute one reviewed deployment invocation

The deployment controller defaults to preflight. Execution is explicit and requires a reviewed plan/hash. Its intended sequence is:

1. Acquire the exclusive KB deployment lock and validate the host, current files, permissions and evidence.
2. Protect backups and the deployment journal.
3. Stage the exact application and dependencies offline without stopping the working service.
4. Verify installed packages and run read-only prerequisite probes; recheck all live baselines.
5. Stop only KB MCP, apply the exact supported service and metadata-route changes, then restart.
6. Run semantic canaries for exact metadata, authentication challenge, rejected invalid/legacy-format credentials, permitted status read, rejected write scope, expected version and public HTTPS.
7. Record success or perform verified OAuth-safe recovery. Refuse to overwrite an intervening website/configuration change.

A first cutover from an old static-token release may have no safe automatic rollback. In that case the controller leaves KB MCP stopped with a recovery journal instead of reopening retired credentials. Existing QDBAuth websites and other services are not migrated or restarted by this workflow.

The controller does not silently create people, broaden grants, migrate other applications, activate emergency access or manufacture proof for missing prerequisites.

Stage 5: accept and operate

After Robert's production connection and the release canaries pass, retire only old KB MCP credentials and onboard approved people through individually tested clients. Verify denied access remains denied after recovery.

Rehearse the separate Auth0 outage procedure before relying on it: independent Odin administration, protected temporary activation, Robert-only reads, denied writes, immediate removal, fixed expiry, audit-storage failure and return to normal OAuth.

Keep source tests, installed-package checks, real-client evidence and production recovery evidence distinct. Store protected incident and deployment evidence under the agreed retention policy. Update the Change Log and operating pages after meaningful changes.

Integrating other services later

The later detailed guide will cover selecting a resource/audience, registering clients/callbacks, choosing permissions, integrating the shared verifier, defining current access policy, testing discovery and claims, validating audit/revocation, packaging, staged cutover and support ownership.

Those services keep existing authentication until their own reviewed migration. No integration is completed merely by adding a client in Auth0.