feat(portal-bff): entra config foundation — boot validator + auth module
CI / scan (pull_request) Successful in 2m21s
CI / commits (pull_request) Successful in 2m31s
CI / check (pull_request) Successful in 2m37s
CI / a11y (pull_request) Successful in 2m7s
CI / perf (pull_request) Successful in 4m54s

First step of ADR-0009 wiring. Captures the Entra app-registration
env vars in the boot pipeline so subsequent PRs can plug
`@azure/msal-node` straight onto a typed, already-validated config
without re-reading process.env. No MSAL client, no OIDC routes, no
session integration yet — those land in follow-up PRs.

What lands:

- `.env.example` promotes the Entra block from its previous "Future
  env vars" comment stub to an active configuration section. Six
  keys: `ENTRA_INSTANCE_URL`, `ENTRA_TENANT_ID`, `ENTRA_CLIENT_ID`,
  `ENTRA_CLIENT_SECRET`, `ENTRA_REDIRECT_URI`,
  `ENTRA_POST_LOGOUT_REDIRECT_URI`. UUID + URL placeholders so the
  spec test for the "still-the-placeholder" guard has a real target.
  Multi-tenant `ENTRA_ACCEPTED_TENANT_IDS` stays in the future-vars
  comment until External ID activation lands.
- `apps/portal-bff/src/config/check-entra-config.ts` — boot
  validator mirroring `check-database-url.ts`. Asserts every required
  key is present, validates the instance URL is `https://` and ends
  with `/`, the tenant + client IDs are UUIDs, none of them are the
  literal .env.example placeholder, and the two redirect URIs are
  parseable URLs. Returns a typed `EntraConfig` object with a
  pre-computed `authority` field (`${instanceUrl}${tenantId}`) so
  the MSAL factory in the next PR does not re-derive it.
- `check-entra-config.spec.ts` — covers the happy path plus eight
  failure modes (missing keys, non-https instance, missing trailing
  slash, non-UUID tenant, placeholder UUID, placeholder secret,
  invalid redirect URI, http redirect for local dev).
- `apps/portal-bff/src/auth/auth.module.ts` — `AuthModule` whose
  v1 surface is a single provider: the parsed `EntraConfig` keyed by
  the `ENTRA_CONFIG` injection token. Factory delegates to
  `assertEntraConfig()`. Module is non-global so consumers state
  intent by importing it.
- `apps/portal-bff/src/auth/entra-config.token.ts` —
  `ENTRA_CONFIG` string token + `EntraConfig` type re-export. The
  pattern subsequent modules will use:
  `@Inject(ENTRA_CONFIG) private readonly entra: EntraConfig`.
- `auth.module.spec.ts` — verifies the provider resolves the typed
  config, and that compilation fails when an env var is missing
  (boot-failure behaviour is preserved across the DI boundary).
- `main.ts` calls `assertEntraConfig()` alongside
  `assertDatabaseUrl()` so misconfiguration fails fast at boot
  rather than mid-request (per ADR-0018 §"BFF env-var loading").
- `AppModule` imports `AuthModule`.

Verification: 29 / 29 specs (was 20; +9 from the new entra-config
spec + auth.module spec), lint clean, webpack build green.

Naming: chose `ENTRA_*` rather than `AZURE_AD_*` to align with ADR
text (Microsoft Entra ID, post-2023 rebrand). The values you copy
from the Entra app-registration UI go into `apps/portal-bff/.env`
(git-ignored).
This commit is contained in:
Julien Gautier
2026-05-12 02:22:52 +02:00
parent cb69a692e7
commit 7992a5ba14
8 changed files with 348 additions and 8 deletions
+34 -8
View File
@@ -34,16 +34,42 @@ OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
# Collector (per ADR-0012). Override only for spike investigations.
OTEL_TRACES_SAMPLER=always_on
# Identity / Entra ID app registration (per ADR-0008 / ADR-0009)
# Values come from the project's Entra application registration in the
# Azure Admin Center → App registrations → APF Portal. The four
# *_INSTANCE_URL / *_TENANT_ID / *_CLIENT_ID / *_CLIENT_SECRET keys
# are mandatory; the BFF refuses to boot without them (see
# apps/portal-bff/src/config/check-entra-config.ts).
#
# ENTRA_INSTANCE_URL is the Microsoft login endpoint — usually
# https://login.microsoftonline.com/. The authority used by MSAL is
# `${ENTRA_INSTANCE_URL}${ENTRA_TENANT_ID}` for single-tenant flows,
# or `${ENTRA_INSTANCE_URL}organizations` / `common` for multi-tenant
# (per ADR-0008's dual-audience design). v1 uses the tenant-scoped
# authority; the multi-tenant switch lands when External ID activation
# is needed.
#
# ENTRA_CLIENT_SECRET is the high-value secret of this set. Never
# commit a real value. Production manages it via the deploy platform's
# secret manager (future infrastructure ADR).
ENTRA_INSTANCE_URL=https://login.microsoftonline.com/
ENTRA_TENANT_ID=00000000-0000-0000-0000-000000000000
ENTRA_CLIENT_ID=00000000-0000-0000-0000-000000000000
ENTRA_CLIENT_SECRET=replace_with_real_value
# Redirect URIs registered in Entra alongside the same client id. Both
# `/auth/callback` and `/auth/logout` paths are mounted by the BFF
# once the OIDC routes land in a subsequent PR.
ENTRA_REDIRECT_URI=http://localhost:3000/api/auth/callback
ENTRA_POST_LOGOUT_REDIRECT_URI=http://localhost:4200/
# Future env vars introduced by upcoming phases / ADRs:
#
# Auth flow (ADR-0009):
# ENTRA_TENANT_ID
# ENTRA_CLIENT_ID
# ENTRA_CLIENT_SECRET (or ENTRA_CLIENT_CERT_PATH)
# ENTRA_ACCEPTED_TENANT_IDS
# ENTRA_REDIRECT_URI
# ENTRA_POST_LOGOUT_REDIRECT_URI
# SESSION_SECRET
# Auth flow (ADR-0009) — additional keys wired as the routes land:
# ENTRA_CLIENT_CERT_PATH (alternative to ENTRA_CLIENT_SECRET)
# ENTRA_ACCEPTED_TENANT_IDS (CSV; restricts which tenants can sign in
# in the multi-tenant phase — empty means
# "only ENTRA_TENANT_ID is accepted")
# SESSION_SECRET (cookie signing key, see Sessions below)
#
# Sessions (ADR-0010):
# REDIS_URL (or REDIS_SENTINEL_HOSTS + REDIS_SENTINEL_NAME)