What does it do? 

SSO Auth integrates Shibboleth-based single sign-on (SSO) into TYPO3. It provides a dedicated TYPO3 authentication service and optional user provisioning for frontend and backend accounts.

Features 

• SSO authentication service for TYPO3 frontend and backend login
• Dedicated backend login provider with an SSO button
• Frontend login plugin with SSO login and logout flow
• Optional auto-import and update of FE users from IdP attributes
• Optional auto-import and update of BE users from IdP attributes
• FE and BE group mapping based on affiliation attributes
• Frontend middleware to recover from stale FE session cookies during SSO
• Hook extension points for custom group assignment and onlySsoBE handling

How SSO requests are detected 

The extension treats a request as SSO-related when one of these conditions is true:

• AUTH_TYPE=shibboleth (case-insensitive)
• Shib_Session_ID exists
• REDIRECT_Shib_Session_ID exists

This logic is implemented in SsoRequestDetector.

Compatibility 

According to composer.json the extension supports:

• TYPO3 ^12.4 || ^13.4
• PHP ^8.1 || ^8.2 || ^8.3 || ^8.4 || ^8.5

Requirements 

• TYPO3 12.4 LTS, 13.4 LTS or 14
• PHP 8.1 or newer (see exact constraints in composer.json)
• Working SSO/IdP setup (e.g. Shibboleth SP) providing server variables such as REMOTE_USER

Install via Composer 

Run in your TYPO3 project root:

composer require davitec/dv-sso-auth

For Composer-based installations the extension is activated automatically.

If required, verify activation in Admin Tools > Extension Manager.

Configure extension settings 

Open Admin Tools > Settings > Extension Configuration and configure dv_sso_auth.

Minimum useful setup:

1. Enable at least one login context:

   • enableBE for TYPO3 backend SSO
   • enableFE for TYPO3 frontend SSO

2. Set handler paths if your Shibboleth endpoints differ:

   • loginHandler (default: /Shibboleth.sso/Login)
   • logoutHandler (default: /Shibboleth.sso/Logout)

3. Verify IdP variable mapping:

   • remoteUser (default: REMOTE_USER)
   • mail (default: mail)
   • displayName (default: displayName)
   • eduPersonAffiliation (default: affiliation)
4. If FE user auto-import is enabled, configure storagePid to the SysFolder that should contain FE users and FE groups.

Include TypoScript 

The extension provides TypoScript in:

• EXT:dv_sso_auth/Configuration/TypoScript/constants.typoscript
• EXT:dv_sso_auth/Configuration/TypoScript/setup.typoscript

Import it in your site package TypoScript:

@import 'EXT:dv_sso_auth/Configuration/TypoScript/constants.typoscript'
@import 'EXT:dv_sso_auth/Configuration/TypoScript/setup.typoscript'

Frontend plugin setup 

For frontend SSO, create a content element with plugin SSO Login (dvssoauth_login).

If enableFE is active, the plugin provides a FlexForm field settings.redirectPage to define the page shown after successful login when no redirect_url parameter is present.

Quick verification 

1. Frontend: open a page with the SSO Login plugin and trigger login.
2. Backend: open /typo3/login and verify the SSO button is available when enableBE is enabled.
3. Confirm that authenticated users are matched by username against the configured remoteUser server variable.

Extension configuration (ext_conf_template) 

Main settings are configured in TYPO3 extension configuration for dv_sso_auth.

TypoScript 

The extension ships with TypoScript constants and setup for plugin view paths:

plugin.tx_dvssoauth {
  view {
    templateRootPath = EXT:dv_sso_auth/Resources/Private/Templates/
    partialRootPath = EXT:dv_sso_auth/Resources/Private/Partials/
    layoutRootPath = EXT:dv_sso_auth/Resources/Private/Layouts/
  }
}

If needed, override these paths in your site package.

Frontend plugin and FlexForm 

The plugin is registered as dvssoauth_login.

Available FlexForm settings:

• settings.redirectPage: page used after successful login if no explicit redirect_url was passed.
• settings.logoutRedirectPage: currently defined in FlexForm but not used in controller logic.

Server variable resolution 

Server variables are resolved with fallback handling:

• direct key lookup (example: REMOTE_USER)
• prefixed lookup with REDIRECT_ (example: REDIRECT_REMOTE_USER)
• scan all scalar $_SERVER keys and strip the REDIRECT_ prefix

This makes setups behind Apache rewrite/proxy layers more robust.

Affiliation parsing 

Affiliations are parsed from the configured server variable (eduPersonAffiliation):

• split by ;
• trim whitespace
• strip domain suffixes after @ (member@example.org becomes member)
• deduplicate values

For FE users, if no affiliation is available, the fallback group title member is used.

Hooks / extension points 

The auth service exposes extension points through $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['dv_sso_auth']:

• getFEUserGroups: post-process FE group UID list
• getBEUserGroups: post-process BE group UID list
• onlySsoFunc: custom behavior when onlySsoBE denies non-SSO login

Example registration:

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['dv_sso_auth']['getFEUserGroups'][]
    = \Vendor\Site\Auth\FrontendGroupProcessor::class;

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['dv_sso_auth']['getBEUserGroups'][]
    = \Vendor\Site\Auth\BackendGroupProcessor::class;

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['dv_sso_auth']['onlySsoFunc'][]
    = \Vendor\Site\Auth\OnlySsoProcessor::class;

Expected processor methods:

public function getFEUserGroups(array $groupUids): array {}
public function getBEUserGroups(array $groupUids): array {}
public function onlySsoFunc(?string $remoteUser): void {}

Frontend login flow 

Use the SSO Login plugin (dvssoauth_login) on a frontend page.

Default behavior:

1. Anonymous users see an SSO Login link.
2. The link points to loginHandler with an encoded target URL.
3. The target URL is normalized to contain logintype=login and pid (including signed PID if TYPO3 login signing is active).
4. After successful IdP authentication, TYPO3 authenticates the user by the configured remoteUser variable.
5. Logged-in users see a logout action that redirects to logoutHandler with return=<site-root-url>.

Redirect behavior after frontend login 

After login, FrontendLoginController::loginSuccessAction() redirects in this order:

1. redirect_url request parameter (if present)
2. FlexForm setting settings.redirectPage (if configured)
3. Otherwise, the plugin renders the logout view directly

Backend login flow 

When enableBE is enabled:

• A dedicated backend login provider is registered.
• TYPO3 login page (/typo3/login) shows an SSO login button.
• The login button points to loginHandler with target /typo3/?login_status=login.
• On backend logout, the extension removes the first cookie whose name starts with _shibsession_.

Restrict backend access to SSO only 

Set onlySsoBE = 1 to deny backend login attempts without valid SSO context.

Behavior on denied login:

• If EXTCONF['dv_sso_auth']['onlySsoFunc'] handlers are registered, they are executed.
• Otherwise, the service throws a backend exception (Login without SSO is not permitted.).

Auto-import and updates 

Recover from stale FE session cookies 

The middleware ResetBrokenFrontendSessionMiddleware handles a common edge case:

• A request has an FE session cookie and is SSO-related.
• TYPO3 responds with 403 because session/auth state is stale.

Then the middleware:

1. Expires the FE cookie.
2. Redirects once to the same URL with ssoSessionRetry=1.
3. If retry still returns 403, the response is returned as-is (no loop).

Typical setup example 

Root
+-- Login
|   Content: SSO Login plugin
+-- Protected area
+-- Logged-in landing page (optional, used as redirectPage)
+-- Storage (SysFolder, not in menu)
    Stores: FE users and FE groups for auto-import

Configuration summary for this setup:

• enableFE = 1
• enableAutoImport = 1 (optional)
• storagePid = <uid-of-storage-folder>
• FlexForm settings.redirectPage = <uid-of-landing-page> (optional)