---
title: Logging
url: "https://b13.com/products/single-sign-on-for-typo3/documentation/logging"
date: 2026-09-10
modified: 2026-11-10
---

# Logging

![Icon featuring a key and overlapping squares, symbolizing security or access control.](https://b13.com/fileadmin/_processed_/0/a/csm_sharing-ext-SingleSignOn-S_512e772865.webp)

  Documentation
===============

 TYPO3 Module “Single-Sign-On”
 Version 2.0.3 (04 Nov 2026)

   Chapters of this Documentation        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](https://b13.com/products/single-sign-on-for-typo3/documentation/running-behind-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](https://b13.com/products/single-sign-on-for-typo3/documentation/user-federation#c12394) |

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.](https://b13.com/fileadmin/_processed_/a/b/csm_Documentation-Images-sys-log-rejected-login_6a380729b1.webp)

   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`:

     Copy

```
```
$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](https://b13.com/products/single-sign-on-for-typo3/documentation/user-federation#c12395), naming the username. **Look here first when a login fails** |
| `info` | A password login rejected because [`enforceSSO`](https://b13.com/products/single-sign-on-for-typo3/documentation/configuration#c12338) is on, and a user creation cancelled by a [listener](https://b13.com/products/single-sign-on-for-typo3/documentation/events#c12402) |
| `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.