feat(portal-bff): extract Entra roles claim onto AuthenticatedUser #126

Merged

julien merged 1 commits from feat/portal-bff-extract-roles-claim into main 2026-05-14 00:30:39 +02:00

Conversation 0 Commits 1 Files Changed 4

+92 -7

julien commented 2026-05-14 00:30:29 +02:00

Owner

Copy Link

Copy Source

Summary

First step in the portal-admin audit-log-viewer workstream (per ADR-0020). The BFF's AdminRoleGuard (next PR) needs to read session.user.roles to enforce admin-only access to /api/admin/*. Today the session carries { oid, tid, username, displayName, amr } — the roles claim is dropped on the floor when the ID token comes back from Entra.

This PR closes that gap:

• Adds roles: readonly string[] to AuthenticatedUser and threads it through toAuthenticatedUser().
• The field flows onto req.session.user automatically via the existing module-augmentation chain in session.types.ts — no extra wiring.

Defensive parsing

Mirrors the existing amr extraction pattern:

Input claim shape	Result
["admin", "editor"]	["admin", "editor"]
Claim absent	[]
Non-array (e.g. "admin")	[]
Mixed types (e.g. ["admin", 42, null, "editor"])	["admin", "editor"]

Empty array means "user has no app role assigned", not "claim was unparseable" — both collapse to the same value because both are equally non-authoritative for the admin guard.

Why this is its own PR

The AdminRoleGuard + @RequireAdmin() decorator + first /api/admin/me self-test endpoint will follow in the next PR. Splitting the claim extraction out makes both diffs trivial to read and lets the second PR focus on guard semantics + audit emission without the mechanical fixture updates that came with adding a new AuthenticatedUser field.

Surface impact — none yet

• PublicUser (the SPA-facing shape returned by GET /api/auth/me) is deliberately unchanged. Exposing roles to the SPA happens in the next PR alongside the conditional admin-link rendering — without a consumer in this PR it would be dead code.
• Audit pipeline unchanged. SignInActor carries { oid, amr } only; the audit log doesn't need roles and won't get it.
• No new env vars, no new dependencies.

Test plan

• pnpm nx test portal-bff — 203 specs pass (was 199; +4 new specs covering the four parsing cases above).
• pnpm exec nx affected -t format:check lint test build --base=origin/main — clean (the pre-existing _res / _next warnings in rate-limit.middleware.ts are unrelated).
• Existing fixtures in auth.controller.spec.ts, auth.service.spec.ts, absolute-timeout.middleware.spec.ts updated with roles: [].
• e2e — would require the admin app role to be declared on the Entra registration and assigned to a test user. Out of scope for this PR; will be validated when the AdminRoleGuard lands and there is a 403 to observe.

## Summary First step in the `portal-admin` audit-log-viewer workstream (per [ADR-0020](docs/decisions/0020-portal-admin-app.md)). The BFF's `AdminRoleGuard` (next PR) needs to read `session.user.roles` to enforce admin-only access to `/api/admin/*`. Today the session carries `{ oid, tid, username, displayName, amr }` — the `roles` claim is dropped on the floor when the ID token comes back from Entra. This PR closes that gap: - Adds `roles: readonly string[]` to [AuthenticatedUser](apps/portal-bff/src/auth/auth.service.ts) and threads it through `toAuthenticatedUser()`. - The field flows onto `req.session.user` automatically via the existing module-augmentation chain in [session.types.ts](apps/portal-bff/src/session/session.types.ts) — no extra wiring. ## Defensive parsing Mirrors the existing `amr` extraction pattern: | Input claim shape | Result | | --- | --- | | `["admin", "editor"]` | `["admin", "editor"]` | | Claim absent | `[]` | | Non-array (e.g. `"admin"`) | `[]` | | Mixed types (e.g. `["admin", 42, null, "editor"]`) | `["admin", "editor"]` | Empty array means **"user has no app role assigned"**, not **"claim was unparseable"** — both collapse to the same value because both are equally non-authoritative for the admin guard. ## Why this is its own PR The `AdminRoleGuard` + `@RequireAdmin()` decorator + first `/api/admin/me` self-test endpoint will follow in the next PR. Splitting the claim extraction out makes both diffs trivial to read and lets the second PR focus on guard semantics + audit emission without the mechanical fixture updates that came with adding a new `AuthenticatedUser` field. ## Surface impact — none yet - `PublicUser` (the SPA-facing shape returned by `GET /api/auth/me`) is **deliberately unchanged**. Exposing `roles` to the SPA happens in the next PR alongside the conditional admin-link rendering — without a consumer in this PR it would be dead code. - Audit pipeline unchanged. `SignInActor` carries `{ oid, amr }` only; the audit log doesn't need `roles` and won't get it. - No new env vars, no new dependencies. ## Test plan - [x] `pnpm nx test portal-bff` — **203 specs pass** (was 199; +4 new specs covering the four parsing cases above). - [x] `pnpm exec nx affected -t format:check lint test build --base=origin/main` — clean (the pre-existing `_res` / `_next` warnings in `rate-limit.middleware.ts` are unrelated). - [x] Existing fixtures in [auth.controller.spec.ts](apps/portal-bff/src/auth/auth.controller.spec.ts), [auth.service.spec.ts](apps/portal-bff/src/auth/auth.service.spec.ts), [absolute-timeout.middleware.spec.ts](apps/portal-bff/src/session/absolute-timeout.middleware.spec.ts) updated with `roles: []`. - [ ] e2e — would require the `admin` app role to be declared on the Entra registration and assigned to a test user. Out of scope for this PR; will be validated when the `AdminRoleGuard` lands and there is a 403 to observe.

julien added 1 commit 2026-05-14 00:30:29 +02:00

feat(portal-bff): extract Entra roles claim onto AuthenticatedUser ... 0e5e6904b5

Adds a `roles: readonly string[]` field to `AuthenticatedUser` and
threads it through `toAuthenticatedUser()`. Entra includes the
`roles` claim in the ID token when the user has at least one app
role assigned on the BFF's app registration; the field flows onto
`session.user` via the existing module-augmentation chain.

No consumer yet — this is the prerequisite for the `AdminRoleGuard`
and `@RequireAdmin()` decorator landing in the next PR per ADR-0020.

Defensive parsing mirrors the `amr` claim: non-array claim → empty
array; non-string entries filtered out. Empty array means "no app
role assigned", not "claim unparseable".

Tests: +4 specs covering claim present, absent, non-array, and
mixed-type entries.

julien merged commit f9f0151717 into main 2026-05-14 00:30:39 +02:00

julien deleted branch feat/portal-bff-extract-roles-claim 2026-05-14 00:30:41 +02:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

adastra-bot (AdAstra Bot) julien (Julien Gautier)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: julien/apf_portal#126