Three Qvantum web tools, one Microsoft sign-in — explained for everyone·with a deep-dive on tap·June 2026
Three of Qvantum's internal web tools — the NPI/CPI dashboard, the AI hub, and the UK Document Builder — now require you to sign in with your Qvantum account before showing anything. Only Qvantum employees get in; everyone else is turned away at the door. This page explains, without code, how the pages are built, how a change goes live, and how the sign-in gate works — so anyone can keep it running.
Follow the flow top to bottom. Everything funnels through one sign-in gate before it reaches an employee.
Tip: click a tool to trace its path · hover any node to focus it
| Tool | What it's for | GitHub repo | Azure app / host | Sign-in |
|---|---|---|---|---|
| NPI/CPI dashboard | Weekly project-status dashboard for management | QvantumSiteManager/ |
nice-stone-05b579003 |
Config ready |
| AI hub | The AI@Qvantum home page & tutorials | QvantumSiteManager/ |
kind-coast-0b353fb03 |
Config ready |
| UK Document Builder | Builds branded, compliant UK customer documents | QvantumSiteManager/ |
uk.documentbuilder.qvantum.com (zealous-pond-0f610f103) |
Live |
All three are plain static sites (HTML/CSS/JS) — no database, no live server code. That's why they're cheap, safe, and easy to gate.
"/*" with "allowedRoles":["authenticated"]. An unauthenticated request gets a 401.responseOverrides rule turns the 401 into a 302 redirect to /.auth/login/aad → login.microsoftonline.com./.auth/me returns your identity; /.auth/* is excluded from app routing so the login round-trip isn't swallowed./login and /logout are convenience routes.home_work/<tool>/. The dashboard publishes only from its site/ build-output folder — the project root holds .env/secrets that must never be committed.git push to that tool's repo.github-work SSH alias → QvantumSiteManager/<repo>, main branch only..github/workflows/azure-static-web-apps-<resource>.yml runs Azure/static-web-apps-deploy@v1 with a deploy-token secret and skip_app_build: true for static sites.In short: edit → push → it goes live automatically. No build servers to babysit.
staticwebapp.config.json turns a public site into a gated one. There is no other "auth code."
"auth": { "identityProviders": { "azureActiveDirectory": { "registration": { "openIdIssuer": ".../606f0645-…/v2.0", // 1 · single-tenant Qvantum issuer "clientIdSettingName": "AZURE_CLIENT_ID", // id/secret are Azure app settings, "clientSecretSettingName": "AZURE_CLIENT_SECRET" // NOT in the repo}}}},"routes": [ { "route": "/login", "redirect": "/.auth/login/aad" }, { "route": "/logout", "redirect": "/.auth/logout" }, { "route": "/*", "allowedRoles": ["authenticated"] } // 2 · everything is gated],"responseOverrides": { "401": { "statusCode": 302, "redirect": "/.auth/login/aad" } }, // 3 · denied → sign in"navigationFallback": { "exclude": ["/.auth/*","/.swa/*","/assets/*","…"] } // 4 · don't swallow login
Points sign-in at the Qvantum Entra tenant; the secret stays in Azure.
Every page needs a signed-in user.
Blocked visitors are bounced to Microsoft instead of seeing a bare 401.
The SPA rewrite must exclude /.auth/* and /.swa/* or login breaks.
Created & owned on the Azure/IT side (Wekudata / Jonathan Hjort), not in any repo.
AZURE_CLIENT_ID; not secret.Use the exact app-setting names AZURE_CLIENT_ID / AZURE_CLIENT_SECRET (an earlier AAD_* attempt 404'd at /.auth/login/aad).
Always exclude /.auth/* (and /.swa/*) from navigationFallback.
skip_app_build: true for static sites (Oryx assumed Node from a root package.json and failed).
Sign-in loop after MFA = fix on the Entra registration (enable ID tokens / v2; redirect URI must be Web type …/.auth/login/aad/callback).
Custom auth requires the Standard tier.
The client secret never leaves Azure; rotate if exposed.
About every 2 years: new client secret → update AZURE_CLIENT_SECRET → delete the old. Calendar a reminder ~2 months early.
Edit → push → it goes live automatically. Nothing else to do.
For the three apps + sign-in after handover; record it in uk_document_builder/docs/access-control-runbook.md.
The Azure/Entra side is run with Wekudata / Jonathan Hjort (Qvantum IT).
To finish each of the remaining two:
AZURE_CLIENT_ID / AZURE_CLIENT_SECRET app settings and confirm Standard tier.feature/access-control → main./.auth/me shows identity; non-Qvantum rejected).Full steps: uk_document_builder/docs/access-control-runbook.md.
Paste into any Mermaid-aware tool to get an editable picture of the flow.
flowchart TD subgraph Tools["3 tools (home_work/)"] D["NPI/CPI dashboard"] A["AI hub"] U["UK Document Builder"] end Tools -->|git push to main| GH["GitHub · QvantumSiteManager"] GH -->|GitHub Actions auto-deploy| AZ["Azure Static Web Apps (Standard)"] AZ -->|staticwebapp.config.json gate| ENTRA{"Microsoft Entra ID — single-tenant"} ENTRA -->|Qvantum account| OK["✅ Employee sees the tool"] ENTRA -->|anyone else| NO["⛔ Blocked"]
The pages are plain static files; GitHub publishes them to Azure on every push; one small config puts the Microsoft sign-in in front of each — so only Qvantum employees can open them. The only recurring chore is rotating one sign-in secret every couple of years.