Context
Follow-up from #75 (WebAuthn step-up / SUF-02). That PR covers the client handling and the E2E acceptance cases that run against the standard Playwright harness (chromium-step-up, profiles local,playwright-test,step-up,step-up-e2e). One acceptance case from the expanded criteria is intentionally deferred here because it needs infrastructure the current E2E harness does not have.
Remaining acceptance case
From #75's acceptance criteria (E2E, step-up enabled):
Social-login (OIDC) account with no passkey → setPassword is governed by allowInitialPasswordSetWithoutStepUp, not a permanent 401.
The mechanism is verified server-side: StepUpService.canSatisfyStepUp returns false for an account that can never satisfy WEBAUTHN step-up (no passkey), so setPassword falls back to allowInitialPasswordSetWithoutStepUp (library #365). What is missing is the browser E2E: sign in with an OIDC provider, then add a password, and confirm it is governed by the fallback rather than returning a permanent 401.
Why it is separate
It needs the Keycloak stack (docker-compose-keycloak.yml + keycloak/realm) running, an app server on a combined docker-keycloak,step-up profile (different datasource and OAuth config than the local E2E server), and an OIDC redirect-login flow in Playwright. That is effectively a new E2E project and CI job, larger than the rest of #75 combined, so it is better as its own PR.
Scope
- A
chromium-step-up-oidc (or similar) Playwright project that brings up Keycloak and runs the app on docker-keycloak,playwright-test,step-up.
- One spec: OIDC login (no passkey) →
POST /user/setPassword is governed by allowInitialPasswordSetWithoutStepUp (403 when false, succeeds when true), not a permanent 401.
- A CI job mirroring the existing
playwright-tests job with the Keycloak service.
Also worth exercising here (noted in #75's owner comment): OIDC login now stamps FACTOR_AUTHORIZATION_CODE, so a freshly-logged-in OIDC user can enroll a first passkey.
Context
Follow-up from #75 (WebAuthn step-up / SUF-02). That PR covers the client handling and the E2E acceptance cases that run against the standard Playwright harness (
chromium-step-up, profileslocal,playwright-test,step-up,step-up-e2e). One acceptance case from the expanded criteria is intentionally deferred here because it needs infrastructure the current E2E harness does not have.Remaining acceptance case
From #75's acceptance criteria (E2E, step-up enabled):
The mechanism is verified server-side:
StepUpService.canSatisfyStepUpreturns false for an account that can never satisfy WEBAUTHN step-up (no passkey), sosetPasswordfalls back toallowInitialPasswordSetWithoutStepUp(library #365). What is missing is the browser E2E: sign in with an OIDC provider, then add a password, and confirm it is governed by the fallback rather than returning a permanent 401.Why it is separate
It needs the Keycloak stack (
docker-compose-keycloak.yml+keycloak/realm) running, an app server on a combineddocker-keycloak,step-upprofile (different datasource and OAuth config than thelocalE2E server), and an OIDC redirect-login flow in Playwright. That is effectively a new E2E project and CI job, larger than the rest of #75 combined, so it is better as its own PR.Scope
chromium-step-up-oidc(or similar) Playwright project that brings up Keycloak and runs the app ondocker-keycloak,playwright-test,step-up.POST /user/setPasswordis governed byallowInitialPasswordSetWithoutStepUp(403 when false, succeeds when true), not a permanent 401.playwright-testsjob with the Keycloak service.Also worth exercising here (noted in #75's owner comment): OIDC login now stamps
FACTOR_AUTHORIZATION_CODE, so a freshly-logged-in OIDC user can enroll a first passkey.