[3.0] External authentication (part 5 of 5) — asks who you are again before the way in changes

[albertlast]

Description

Part 5 of 5, on top of #9491. Review #9381, #9488, #9489 and #9491 first.

Two holes, both about proving it is still you. The second one is a live lockout
that parts 1 to 4 created.

A member with no password could not get into the administration centre.
User::validateSession() is the gate before the admin and moderation areas: it
asks for the password a second time and remembers for an hour that you got it
right. Parts 1 to 4 made accounts that have no password, so that question had no
answer — the member reached a password box they could not fill and was shut out
for good. The comment part 1 left in that method ("nothing in SMF itself creates
a member without a password") stopped being true the moment part 4 landed.

What the gate has always actually read is the stamp in the session, not the
password. So a passkey, or a trip back to the identity provider, now writes the
same stamp, and everything downstream is unchanged.

Adding a way in asked for nothing at all. SMF makes a member retype their
password to turn a second factor off, while parts 2 and 3 let anyone holding
the session attach a passkey or link a provider. That is the more dangerous
direction: the new credential outlives the session it was added from, and
changing the password does not revoke it. ?action=profile;area=passkeys and
;area=linkedaccounts now ask first, and so do the endpoints behind them, for
the request that did not come from those pages at all.

New class SMF\Authentication\StepUp owns the whole question: what a member
may be asked to prove, how long an answer lasts, whether one is still good, and
which methods this particular member could answer with. validateSession() and
ACP::adminLogin() both moved onto it, which also removes the copy of the
purpose-validation they each carried.

Two new sub-actions, ?action=passkey;sa=reauth and
?action=authext;sa=reauth. Neither signs anybody in, links anything or creates
anything — they answer the question and send the member back to the page that
asked it. The OIDC one sends prompt=login and max_age=0, without which the
provider would answer out of the session it already had and prove nothing.

The windows are settings, not opinions — auth_stepup_lifetime (default an
hour, matching today's behaviour) and auth_credentials_lifetime (default five
minutes), beside securityDisable where an admin already decides how much of
this they want. securityDisable_credentials switches the new check off
entirely. Changing the way into an account gets the shorter default because an
hour-old answer is a poor thing to accept for a change that permanent, but that
is the admin's call and not mine.

Three things a proof must not do, and now cannot:

• a passkey belonging to somebody else proves nothing about the member holding
  the session — the credential has to be theirs;
• signing in at a provider account that is not the one linked here proves
  nothing either;
• a challenge issued to sign in cannot answer a step up, or the reverse. The
  purpose is recorded with the challenge and checked when it comes back.

A member with no password, no passkey and no linked provider is told so plainly
instead of being handed a form they cannot fill in.

How this was tested

No test suite, so this was driven over real HTTP against the Docker environment,
with a forged authenticator standing in for navigator.credentials and a real
Keycloak standing in for the provider. 106 checks, all passing — 58 for this
PR, plus the 48 from #9491 re-run against it.

Passkey and password step-up, 40 checks:

• the passkeys page stops to ask, and the endpoint behind it refuses on its own
• a password opens it; a wrong password does not
• a passkey opens it too, and sends the member back where they were
• the administration centre: it asks, offers both the password and the
  passkey, and the passkey opens it
• an administrator with no password at all: asked, not shut out — no
  password box, an explanation, the passkey offered, and it lets them in
• refused: a member with no passkey, another member's passkey, a sign-in
  challenge used as a step up, an unrecognised purpose (narrowed, not widened)
• the window is honoured: a fresh answer opens the page, a stale one does not
• with securityDisable_credentials set, nothing asks and nothing refuses
• an account with no method at all is told so, with no password box

Identity provider step-up, 18 checks:

• an account created through the provider, with no password
• the linked accounts page asks, does not ask for a password it hasn't got, and
  offers the provider
• the round trip carries prompt=login, comes back, and opens the page
• nobody is signed in again, nothing is linked twice, no account is created
• an account at the provider that is not the linked one proves nothing, the page
  stays shut, and nothing is written

Regression, 48 checks: #9491's whole suite, re-run. The only change needed was
that its "add a second passkey afterwards" section now has to prove itself
first — which it does with the passkey the member signed up with, since that
account has no password. That is the gate working.

smf_log_errors held only the deliberate refusals afterwards. composer lint,
phplint and the index/licence/EOF/languages checks are clean, and the forum
was put back the way it was found.

Notes for review

• ErrorHandler::fatalLang() accepts a $file parameter and then ignores it,
  reading Errors.php regardless
  (ErrorHandlerService.php:405).
  Not fixed here; it is why stepup_no_method lives in Errors.php while the
  rest of these strings are in Login.php.
• Unrelated, found while checking whether SMF re-authenticates before critical
  changes: completing two factor setup fatals on release-3.0.
  TFASetup::execute() builds the QR URL from Utils::$context['tfa_secret'],
  which validateAndSave() only sets on its failure branch, and the secret is
  not stored either. Reproduced on a clean checkout. Happy to open that
  separately.

Issues References (Fixes|Related|Closes)

Related: #9381, #9488, #9489, #9491