Logging

A failed SSO login shows nothing on screen beyond the login form coming back, so the log is the only place that says why. There are two layers, and they answer different questions.

Rejected Logins in sys_log

Failed SSO logins are written to sys_log and appear in the Log module— Administration > Log in TYPO3 v14, System > Log in v13—next to the successful logins TYPO3 records itself. Set the Channel filter to user to see logins only. Both scopes are recorded; a frontend failure is written with the same columns core uses, so the two look alike in the module.

The module ships with EXT:belog, which has to be installed for it to appear.

Two failures are distinguished, because they call for entirely different fixes:

Entry	Meaning	Where to Look
the response from the identity provider was rejected	The assertion did not pass validation. The entry carries the reason from the SAML toolkit, the toolkit’s error keys, and the assertion consumer service URL the assertion had to be addressed to	A login cancelled at the identity provider, an expired or replayed assertion, a signature that does not verify, or a `Destination` mismatch—the classic symptom of a reverse proxy TYPO3 does not know about
no TYPO3 user for "…"	The identity provider authenticated somebody, but no TYPO3 user matches, and the entry states whether federation was on	Nothing is wrong with the SAML setup. Either the user does not exist, or the lookup does not match them—see Matching an Existing User

The reason in a rejected entry is taken from the response that was posted, before its signature is checked—it can quote a status message the identity provider sent, and equally one that somebody posting a forged response wrote. Anyone can produce such an entry by posting a SAMLResponse to a login form; it does not mean the identity provider was involved.

Entries are recorded as a security notice, with user id 0, because there is no user to attribute them to. Successful logins need no configuration here—core writes them itself, with the resolved TYPO3 username.

This layer only exists because core does not do it. A failed attempt is otherwise sent to the PSR-3 logger at debug level and nowhere else, leaving no trace for anyone not tailing a file. An SSO login can fail in ways a password login cannot, and telling those two rows apart afterwards is the entire point.

The TYPO3 Log module with a single entry, marked with a warning sign, that reads: SSO login attempt from 192.0.2.10 failed, no TYPO3 user for "homer" (federation: enabled). The identity provider authenticated the user, but TYPO3 has no active user record for that name.

Technical Detail in the PSR-3 Logger

Everything else goes to the PSR-3 logger under the B13.SSOAuthentication component, which has no writer of its own by default. To collect it in a separate file, add this to config/system/additional.php:

$GLOBALS['TYPO3_CONF_VARS']['LOG']['B13']['SSOAuthentication']['writerConfiguration'] = [
    \Psr\Log\LogLevel::DEBUG => [
        \TYPO3\CMS\Core\Log\Writer\FileWriter::class => ['logFileInfix' => 'sso'],
    ],
];

That writes to var/log/typo3_sso_*.log. What each level gives you:

Level	What Lands There
`error`	A response that could not be processed at all, claims that could not be restored, and configuration that does not resolve—identity provider metadata that cannot be fetched, or SAML settings the toolkit rejects when building an authentication request
`warning`	A rejected assertion, with the reason, the toolkit’s error keys, and the expected assertion consumer service URL. Also a federation refused by the disabled-user guard, naming the username. Look here first when a login fails
`info`	A password login rejected because `enforceSSO` is on, and a user creation cancelled by a listener
`debug`	The full flow: incoming request URIs in both scopes, the redirect to the identity provider and where it will come back to, the claims that arrived with a successful assertion, each step of resolving them to a TYPO3 user, and the group reconciliation. This is what to switch on while setting an installation up

Do not leave debug on permanently. It writes the complete attribute set of every successful login, and the resulting record update—personal data, into a file TYPO3 does not rotate. warning is the right level for normal operation.

Documentation

Rejected Logins in sys_log

Technical Detail in the PSR-3 Logger