Repository navigation
Sign-in: an administrator is asked for the second factor when signing in to Modgud, not a moment later - #259
Merged
Merged
Conversation
…ds from it Signing in with a password as an administrator who owns a passkey showed the dashboard for a moment and then jumped to the login page for the passkey. The sign-in was evaluated against the portal (the realm's level) and was complete; the dashboard's "recent security events" widget then read /api/admin/auth-log, the administration refused the request for its higher level, and the HTTP client answered the refusal with a redirect. Opening the admin console had the same shape: the shell rendered, its first request was refused, the page was replaced. The rule of ADR 0025 stays as it is — the portal opens at the realm's level, the administration asks for its own (S43). What changes is who finds out, and when: - /api/account/me reports AdministrationNeedsStepUp: the answer the enforcement would give a request to /api/admin/*, including the setup grace a first visit would start (assumed, not stored). - The route guard sends a navigation into /admin to the step-up before the page opens. - Dashboard widgets that read from the administration (recent security events, login providers) show a confirmation in place of their content and request nothing while the session is below that level. - A step-up that finds nothing to raise re-reads the session before it returns, so a stale answer cannot send the user back to the login page. Tests: four integration tests for the /me answer (step-up owed, grace running, grace of zero days, administration at one factor); an e2e spec with a realm administrator below the administration's level — the dashboard stays, no request reaches /api/admin, the admin console asks first. Against the 0.20.1 image the spec fails with the redirect described above. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ion's level ADR 0025, amendment 2. With the realm at `single` and the administration at `multi`, an administrator signing in to Modgud with one factor was let in at the portal's level and asked for the second factor only when something reached for the administration. If the second factor is going to be required, it is asked for in the sign-in. - ISignInRequirementService.ResolveSignInTargetAsync(user, returnUrl): the login page's target once the user is known. For Modgud's own UI and a user holding any permission in Modgud's own Apps it is the administration, when that requires more than the portal. Used by the password, e-mail-code and magic-link sign-ins. - A pending authorization or a device approval as the continuation keeps the App's rules, whoever signs in. - The portal's own level is unchanged; a session below the administration's level (signed in for an App, federated) is handled by the previous commit. An administrator without a second factor now gets the setup offer at the sign-in to Modgud (grace, then required) instead of at the first visit to the administration. Tests: six integration tests for the rule (asked at once after a password and after an e-mail code, an App's rules for an App sign-in, a non-administrator, administration at one factor, the setup offer); tests that needed a single-factor administrator session now get it from a sign-in for an App, and the two about an ordinary user use one. e2e: the sign-in form shows the setup and never the dashboard. Docs: scenario S14, S43 reworded. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The default test user is a realm administrator. Two DCR flow tests seed a passkey for them and need a password-only session; a sign-in to Modgud itself now asks such a user for the passkey (ADR 0025, amendment 2), so the tests sign in with the client's pending authorization as the continuation. CreateAuthenticatedClientAsync takes that continuation as an optional argument. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Signing in to Modgud with a password as an administrator who owns a passkey showed the dashboard for about a second and then jumped to the login page for the passkey.
The sign-in was evaluated against the portal (the realm's level,
single) and was complete. A dashboard widget then read/api/admin/auth-log, the administration refused the request for its higher level, and the HTTP client answered the refusal with a redirect. Opening the admin console had the same shape.What changes
An administrator signs in to Modgud at the administration's level (ADR 0025, amendment 2).
single, nothing changes.A session below the administration's level keeps the portal — an administrator signed in for an App who opens Modgud afterwards, a federated sign-in.
/api/account/mereportsAdministrationNeedsStepUp: the answer the enforcement would give a request to/api/admin/*, including the setup grace a first visit would start (assumed, not stored)./adminto the step-up before the page opens.Behaviour to know about
Tests
/meanswer. Tests that needed a single-factor administrator session now get it from a sign-in for an App.55-administration-step-up.spec.tsagainst the production image: the sign-in form shows the setup and never the dashboard; a session below the level keeps the dashboard with no request to/api/admin; the admin console asks first. Against the 0.20.1 image the dashboard test fails with the redirect described above.Docs:
docs/concepts/sign-in-levels.md(scenario S14, S43 reworded), ADR 0025 amendment 2.🤖 Generated with Claude Code