shibboleth_auth dla TYPO3: Shibboleth Single Sign-On

Jak polskie uczelnie podłączają swoje portale TYPO3 do centralnego zarządzania tożsamością

Kto prowadzi portal TYPO3 na polskiej uczelni, prędzej czy później natrafi na Shibboleth. PIONIER-Id i federacja eduGAIN tworzą największą infrastrukturę Identity-Federation w polskim środowisku akademickim, a każda uczelnia, która chce udostępnić dane badawcze, materiały dydaktyczne lub usługi administracyjne na zewnątrz, musi uwierzytelniać swoich użytkowników wobec Shibboleth Identity Provider. shibboleth_auth to rozszerzenie, które wpasowuje TYPO3 w ten krajobraz: odczytuje asercje SAML poprzedzonego Shibboleth Service Providera i na tej podstawie tworzy fe_users oraz be_users.

Typowe scenariusze zastosowania

Wydział lekarski z 8 000 studentów prowadzi portal TYPO3 z programami klinicznymi. Studenci mają widzieć swoje materiały dydaktyczne po zalogowaniu, a wykładowcy dodatkowo interfejs redakcyjny. Centralny Shibboleth-IdP uniwersytetu dostarcza atrybuty eduPersonAffiliation, schacHomeOrganization oraz unikalny identyfikator. shibboleth_auth przejmuje mapowanie tych atrybutów na grupy TYPO3 i pilnuje, żeby student nigdy nie trafił do backendu, podczas gdy wykładowca automatycznie ląduje w grupie redaktorskiej.

Drugim typowym przypadkiem są instytuty badawcze jak oddziały Polskiej Akademii Nauk albo sieci Łukasiewicza. Ich pracownicy pochodzą z kilkunastu uczelni partnerskich i każdy powinien móc logować się swoim kontem macierzystym do centralnych portali projektowych. shibboleth_auth w połączeniu z Service Providerem podłączonym do eduGAIN umożliwia dokładnie to: gościnny badacz z Uniwersytetu Warszawskiego loguje się swoim kontem AGH do portalu prowadzonego przez Politechnikę Wrocławską, bez konieczności istnienia lokalnego konta.

Trzeci kontekst to administracja publiczna, gdzie instytucje wojewódzkie coraz częściej prowadzą wojewódzkie IdP, aby połączyć konta obywatelskie i dostępy pracowników. Urząd wojewódzki z kilkoma portalami TYPO3 dla różnych departamentów może przez shibboleth_auth podłączyć wszystkie portale do centralnego IdP urzędu i zaoszczędzić sobie odrębnego zarządzania użytkownikami per portal.

Architektura techniczna między SP, SAML i fe_user

shibboleth_auth jest zbudowany inaczej niż klasyczne usługi autoryzacyjne TYPO3: rozszerzenie nie mówi bezpośrednio SAML, lecz deleguje cały protokół do lokalnie zainstalowanego Shibboleth Service Providera. SP, zazwyczaj demon shibd z mod_shib w Apache lub odpowiednim modułem Nginx, przetwarza asercję SAML, waliduje podpisy i certyfikaty oraz udostępnia wyodrębnione atrybuty jako zmienne środowiskowe HTTP. shibboleth_auth odczytuje te zmienne, tworzy lub aktualizuje fe_user i loguje go do sesji TYPO3.

Konfiguracja rozszerzenia odbywa się przez konfigurację rozszerzenia TYPO3 i wzorzec Extbase-Service dla dostawców uwierzytelniania. Mapowanie atrybutów leży w pliku TypoScript albo bezpośrednio w backendzie rozszerzenia: zmienna HTTP po lewej, nazwa pola TYPO3 po prawej, opcjonalnie z transformacjami dla ID grup. Ważna jest kolejność w konfiguracji $TYPO3_CONF_VARS[‘SVCONF’][‘auth’][‘setup’], żeby shibboleth_auth zadziałał przed standardową usługą logowania.

Częste problemy i rozwiązania

Najczęstszym błędem jest pętla przekierowań: użytkownik zostaje odesłany do IdP, wraca, jest ponownie odsyłany do IdP i tak dalej. Przyczyną jest prawie zawsze rozbieżność między domeną sesji SP i domeną TYPO3 albo brakujące ciasteczko, ponieważ SP zapisuje swoją sesję pod innym path, niż oczekuje TYPO3. Rozwiązaniem jest czyste rozdzielenie: sesja SP pod path /Shibboleth.sso, sesja TYPO3 pod / i obie pod tą samą domeną najwyższego poziomu.

Drugi problem dotyczy atrybutów: IdP dostarcza inną nazwę atrybutu, niż oczekuje rozszerzenie. Szczególnie przy federacjach akademickich przestrzenie nazw atrybutów zmieniają się między notacjami OID i URN. Bez czystej normalizacji użytkownik nie trafia do żadnej grupy albo otrzymuje pusty wpis w profilu. Plik attribute-map w SP, który sprowadza stare i nowe nazwy do jednej jednolitej lokalnej nazwy, trwale rozwiązuje ten problem.

Trzeci temat to rotacja certyfikatów. Każdy IdP regularnie wymienia swoje certyfikaty podpisujące i szyfrujące, zazwyczaj co dwa lata. SP musi pobierać nowe certyfikaty przez metadata-feed, inaczej walidacja asercji nagle się psuje. Konfiguracja metadata-providera w shibboleth2.xml powinna zatem zawsze działać z automatycznym interwałem odświeżania rzędu kilku godzin i weryfikacją podpisu wobec federation-signera.

Czwarty obszar problemów to czasy życia sesji. Shibboleth i TYPO3 mają niezależne timeouty: jeśli sesja SP wygaśnie, podczas gdy sesja TYPO3 jest wciąż aktywna, użytkownik widzi wprawdzie swoje chronione treści, ale ponowne logowanie się nie udaje, bo SP nie ma już ważnej asercji. Porządnym rozwiązaniem jest ustawienie obu czasów sesji na tę samą wartość i skonfigurowanie równoległego zachowania wylogowania, tak aby Single Logout faktycznie kończył obie sesje.

Migracja i kompatybilność wersji

shibboleth_auth długo towarzyszył wersjom TYPO3 v9, v10 i v11 przez forki społeczności, sytuacja w v12 i v13 jest jednak różna w zależności od gałęzi forków. Niektóre forki dokonały skoku na usługi autoryzacji oparte na Symfony, inne pozostały na v11. Kto obecnie migruje na v12, powinien przed upgrade’em sprawdzić, czy własny zwój rozszerzenia jest jeszcze utrzymywany, czy lepszym wyborem będzie przejście na rozszerzenie OIDC.

Ścieżka migracji z Shibboleth na OIDC stała się aktualna dla wielu uczelni, odkąd Keycloak i porównywalne brokery tożsamości potrafią obsługiwać klientów SAML i OIDC równolegle. Gosign wielokrotnie towarzyszył takim przejściom i w okresie przejściowym z reguły prowadzi oba ścieżki uwierzytelniania równolegle, tak aby systemy legacy nadal logowały się przez Shibboleth, podczas gdy nowe portale mówią bezpośrednio OIDC.

Kto pozostaje na stałe przy shibboleth_auth, powinien realistycznie oszacować nakład pracy utrzymaniowej. Samo rozszerzenie zmienia się rzadko, ale otaczająca infrastruktura regularnie: Shibboleth SP publikuje aktualizacje bezpieczeństwa, federacje aktualizują metadane i certyfikaty, wersje Apache lub Nginx są wymieniane, a każda z tych zmian może złamać proces logowania. Porządny monitoring pipeline uwierzytelniania z syntetycznymi logowaniami i alertami przy nieudanych asercjach nie jest zatem nice-to-have, tylko częścią koncepcji operacyjnej stabilnej integracji SSO.