Shibboleth dla TYPO3

Uczelnie i instytucje badawcze potrzebują SSO Shibboleth bezpośrednio w TYPO3

W sektorze akademickim Shibboleth jest faktycznym standardem Single Sign-On. Ponad 3 000 instytucji na świecie zorganizowanych jest w federacjach Shibboleth, w Polsce m.in. przez federację PIONIER.Id i federację USOS, łączącą uczelnie wyższe. Rozszerzenie Shibboleth dla TYPO3 integruje Service Provider bezpośrednio z CMS-em. Studenci, wykładowcy i pracownicy logują się swoimi danymi uczelnianymi i otrzymują dostęp do chronionych obszarów frontendu, a w razie potrzeby do backendu TYPO3. Rozszerzenie jest siostrzane wobec shibboleth_auth i dostarcza bazowej integracji dla Shibboleth SP, który musi być zainstalowany na serwerze WWW.

W odróżnieniu od rozszerzenia saml2, implementującego własny SP w PHP, rozszerzenie shibboleth opiera się na natywnym Shibboleth Service Provider (C++ lub Java), działającym jako moduł Apache lub filtr ISAPI. To bardziej odporna architektura w środowiskach o wysokiej dostępności.

Typowe scenariusze dotyczą PIONIER.Id, systemów bibliotecznych i portali badawczych

Podstawowym scenariuszem jest integracja PIONIER.Id na polskich uczelniach. Uniwersytet prowadzi swój portal w TYPO3. Studenci klikają “Login”, są przekierowywani do IdP uczelni, uwierzytelniają się i wracają na stronę TYPO3 z aktywną sesją. Rozszerzenie odczytuje atrybuty Shibboleth ze zmiennych środowiskowych serwera (REMOTE_USER, eppn, mail, affiliation) i tworzy lub aktualizuje użytkownika frontendu TYPO3.

Drugim scenariuszem są dostępy biblioteczne. Biblioteki uczelniane oferują bazy online, e-czasopisma i dokumenty badawcze przez swoje strony TYPO3. Dostęp ograniczony jest do osób związanych z uczelnią. Rozszerzenie Shibboleth sprawdza atrybut “eduPersonEntitlement” i przyznaje wstęp do licencjonowanych treści tylko użytkownikom z wartością “urn:mace:dir:entitlement:common-lib-terms”.

Trzeci scenariusz: zfederowane portale badawcze. Konsorcjum naukowe z partnerami z pięciu uczelni prowadzi wspólny portal w TYPO3. Każdy partner ma własny IdP. Dzięki federacji PIONIER.Id wszyscy pracownicy partnerów mogą się logować, a portal nie musi prowadzić własnych kont. Rozszerzenie przypisuje użytkowników do właściwej grupy partnera na podstawie atrybutu “schacHomeOrganization”.

Architektura techniczna wymaga zainstalowanego Shibboleth SP na serwerze WWW

Samo rozszerzenie nie zawiera stosu SAML. Odczytuje atrybuty, które Shibboleth SP po pomyślnym uwierzytelnieniu udostępnia jako zmienne środowiskowe serwera lub nagłówki HTTP. SP musi być skonfigurowany jako moduł Apache (mod_shib) lub jako autoryzator FastCGI. Dla setupów nginx potrzebny jest Shibboleth SP jako backend FastCGI lub proxy oparte na Lua.

Rozszerzenie TYPO3 rejestruje Authentication Service, który przy każdym logowaniu frontendu lub backendu sprawdza, czy obecne są atrybuty Shibboleth. Jeśli tak, atrybuty są mapowane na pola użytkownika TYPO3: REMOTE_USER na username, mail na email, givenName i sn na first_name i last_name. Przypisanie do grupy odbywa się przez atrybut “eduPersonAffiliation”: student, faculty, staff, employee są mapowane na grupy frontendu TYPO3.

Zarządzanie sesją podąża za cyklem życia Shibboleth: gdy sesja Shibboleth wygasa, użytkownik TYPO3 jest automatycznie wylogowywany. Single Logout (SLO) jest obsługiwane przez Shibboleth SP, rozszerzenie TYPO3 reaguje na zdarzenie wylogowania i niszczy sesję TYPO3.

Częste problemy dotyczą konfiguracji Apache i brakujących atrybutów

Największym problemem jest poprawna konfiguracja Apache. Shibboleth SP musi wiedzieć, które URL-e ma chronić. Błędna dyrektywa Location prowadzi do tego, że SP albo chroni wszystkie strony (również publiczne), albo żadnej. Standardowa konfiguracja chroni /Shibboleth.sso/* dla samego SP i /typo3/ dla backendu. Obszary frontendu chronione są przez Lazy Session: SP ustawia atrybuty, gdy sesja Shibboleth istnieje, ale nie wymusza uwierzytelnienia. Rozszerzenie sprawdza wtedy w frontendzie TYPO3, czy atrybuty są obecne, i pokazuje chronione treści tylko zalogowanym użytkownikom.

Drugi problem: brakujące lub puste atrybuty. Nie każdy IdP dostarcza wszystkich atrybutów. Gdy IdP nie udostępnia atrybutu “mail”, rozszerzenie nie może wpisać adresu mailowego do użytkownika TYPO3. Rozwiązanie: ustalić z operatorem IdP (centrum obliczeniowym uczelni), które atrybuty są zwolnione dla SP, i odpowiednio skonfigurować mapowanie atrybutów w rozszerzeniu.

Trzeci temat: wdrożenia kontenerowe. Instalacje TYPO3 w Dockerze często nie mają Apache z mod_shib. Alternatywą jest Shibboleth SP jako reverse proxy przed kontenerem TYPO3, przekazujący atrybuty jako nagłówki HTTP. Rozszerzenie musi wtedy być skonfigurowane tak, aby odczytywało atrybuty z nagłówków, a nie ze zmiennych środowiskowych. Ważne: nagłówki muszą być chronione przed spoofingiem - reverse proxy musi usuwać przychodzące nagłówki o nazwach atrybutów Shibboleth.

TYPO3 v12 działa, kompatybilność z v13 wymaga sprawdzenia API Authentication Service

Rozszerzenie shibboleth wykorzystuje API Authentication Service TYPO3, które od lat jest stabilne, ale w v13 zostało dostosowane. Pod TYPO3 v12 aktualna wersja działa bez problemów. Dla v13 konieczna jest aktualizacja rejestracji service’u i konfiguracji middleware. Uczelnie planujące upgrade TYPO3 powinny włączyć integrację SSO jako osobny blok testowy do planu upgrade’u. Gosign zaleca, by równolegle z rozszerzeniem shibboleth ewaluować rozszerzenie oidc, ponieważ wiele IdP wspiera obecnie zarówno SAML, jak i OIDC, a OIDC umożliwia prostszą architekturę bez Shibboleth SP na serwerze.