Na univerzitě může jediný člověk potřebovat přístup na hlavní webové stránky, fakultní portál, knihovní systém, výukovou platformu a tucet dalších aplikací — a nikdo se nechce přihlašovat zvlášť do každé z nich. Jednotné přihlášení (SSO) tento problém řeší tím, že uživateli umožňuje ověřit se pouze jednou pomocí jedné sady institucionálních přihlašovacích údajů a získat přístup ke všem propojeným systémům. Pro stránky Drupal, které stojí v centru digitální přítomnosti univerzity, patří integrace s institucionálním SSO mezi nejdůležitější součásti celého řešení.
Tento průvodce vysvětluje, jak funguje integrace Drupal SSO a, což je důležitější, jak zvolit správný přístup. Popíšeme čtyři technologie, na které univerzity spoléhají — SAML, Shibboleth, LDAP a CAS — kdy se která z nich hodí, jak integrace funguje na straně Drupalu a jaká rozhodnutí týkající se správy identit a bezpečnosti většina návodů krok za krokem vynechává.
Co jednotné přihlášení skutečně znamená
Jednotné přihlášení je model ověřování, při kterém se uživatel jednou přihlásí u důvěryhodné centrální autority a poté je automaticky rozpoznán každou aplikací, která je s ní propojena. Klíčovým principem — a zároveň bezpečnostní výhodou — je, že jednotlivé aplikace nikdy nepracují s heslem uživatele. Díky SSO se přihlašovací údaje ověřují na jednom místě podle jedné sady zásad, místo aby je každý systém ukládal a kontroloval zvlášť.
Pro univerzitu je to důležité na několika úrovních zároveň. Studenti a zaměstnanci získají jednu identitu napříč desítkami služeb. IT tým spravuje ověřování centrálně, přičemž všude uplatňuje jednotná pravidla pro hesla a vícefaktorové ověřování. A když někdo instituci opustí, deaktivace jednoho centrálního účtu odstřihne přístup ke všemu, místo aby zůstaly osiřelé přihlašovací údaje roztroušené po různých systémech. Právě tato kombinace pohodlí a kontroly je důvodem, proč je SSO v podstatě nezbytností pro každou serióznější institucionální webovou platformu.
Základní stavební kámen: Poskytovatel identity a poskytovatel služby
Každé nastavení SSO zahrnuje dvě role a jejich pochopení objasní vše ostatní.
Poskytovatel identity (IdP) je důvěryhodná centrální autorita, která spravuje identity uživatelů a ověřuje přihlašovací údaje — může jít o institucionální službu Shibboleth, Active Directory nebo server CAS. Poskytovatel služby (SP) je aplikace, ke které se uživatel chce dostat — v tomto případě stránky Drupal. Když se uživatel pokusí přistoupit k SP Drupal, ten předá ověření IdP; IdP uživatele ověří a odešle zpět potvrzení spolu s atributy, jako je jméno, e-mail a role; a Drupal na základě této důvěryhodné odpovědi udělí přístup. Ve standardním univerzitním nastavení funguje Drupal jako poskytovatel služby a stávající systém instituce jako poskytovatel identity. Správné nastavení tohoto vztahu je základem každé integrace SSO.
Čtyři přístupy: SAML, Shibboleth, LDAP a CAS
Univerzity se pro SSO obvykle spoléhají na jednu ze čtyř technologií. Ty se svým účelem překrývají, ale liší se původem, mechanismem a tím, kde se hodí nejlépe.
SAML
SAML (Security Assertion Markup Language) je otevřený standard, na kterém stojí většina moderních podnikových řešení SSO. Jedná se o protokol založený na XML pro výměnu autentizačních a autorizačních dat mezi IdP a SP, který se integruje prakticky s každou hlavní identitní platformou — Microsoft Entra ID, Okta, ADFS, Google Workspace a dalšími. V Drupalu je SAML řešen prostřednictvím přispěvatelských modulů, které stránkám umožňují fungovat jako poskytovatel služby a delegovat ověřování na jakéhokoli IdP kompatibilního se SAML. Jde o nejšířeji kompatibilní volbu a společnou platformu, kterou dokáže „mluvit" většina ostatních systémů.
Shibboleth
Shibboleth je konkrétní, široce nasazená implementace SAML, hluboce zakořeněná v akademickém světě. Je páteří federovaného přístupu ve vysokoškolském vzdělávání a výzkumu — technologií, která stojí za národními i mezinárodními akademickými federacemi umožňujícími studentovi přihlásit se na jedné instituci a získat přístup ke zdrojům na jiné. Technicky vzato je integrace Drupalu se Shibboleth integrací SAML: Drupal funguje jako poskytovatel služby SAML a Shibboleth slouží jako poskytovatel identity. Pokud je vaše instituce součástí akademické identitní federace, bude Shibboleth s velkou pravděpodobností systémem, k němuž se budete připojovat.
LDAP
LDAP (Lightweight Directory Access Protocol) není protokolem SSO ve stejném smyslu jako SAML — jde o protokol pro dotazování se do adresáře uživatelů, nejčastěji Microsoft Active Directory. Jeho úlohou na univerzitě je být základním zdrojem identity: uchovává informace o tom, kdo existuje, jejich členství ve skupinách a jejich atributy. Integrace Drupalu s LDAP umožňuje uživatelům přihlašovat se pomocí přihlašovacích údajů z adresáře a může automaticky vytvářet účty Drupal a přiřazovat role na základě skupin v adresáři. LDAP je často vrstvou, která stojí za protokolem SSO, spíše než jeho náhradou, a je obzvláště běžný tam, kde instituce provozuje prostředí Microsoft.
CAS
CAS (Central Authentication Service) je open-source protokol SSO s kořeny na Yaleově univerzitě, který zůstává ve vysokoškolském prostředí široce používán. Byl navržen speciálně pro řešení problému SSO u webových aplikací a bez potíží funguje vedle autorizačních úložišť, jako je LDAP. V Drupalu integrace CAS přesměruje uživatele na centrální server CAS instituce k ověření a poté je vrátí zpět na stránky jako přihlášeného uživatele, přičemž role lze přiřazovat na základě odpovědi CAS. Pro univerzity, které již provozují nasazení CAS v rámci celého kampusu, je propojení Drupalu s ním přirozenou volbou.
Který protokol by měla univerzita zvolit?
V praxi je volba obvykle dána tím, co instituce již provozuje — Drupal se připojuje ke stávajícímu IdP, nikoli naopak. Následující tabulka shrnuje, kdy se který přístup hodí.
| Přístup | Co to je | Nejvhodnější pro |
|---|---|---|
| SAML | Otevřený standard pro federované ověřování; nejširší kompatibilita. | Připojení k Entra ID, Okta, ADFS nebo jakémukoli IdP se SAML. |
| Shibboleth | Akademická implementace SAML; standard pro výzkumné federace. | Instituce zapojené do národní nebo mezinárodní akademické federace. |
| LDAP | Adresářový protokol; základní zdroj identity uživatele. | Prostředí Microsoft Active Directory; přidělování rolí. |
| CAS | Open-source protokol SSO zaměřený na web, běžný na univerzitních kampusech. | Instituce s existujícím serverem CAS pro celý kampus. |
Praktické pravidlo je jednoduché: identifikujte poskytovatele identity, kterého vaše instituce již provozuje, a poté zvolte integraci Drupalu, která s ním umí komunikovat. Univerzita v akademické federaci připojí Drupal ke Shibboleth; instituce standardizovaná na Microsoft se připojí přes SAML k Entra ID nebo přes LDAP k Active Directory; instituce provozující kampusový server CAS se připojí k CAS. Málokdy jde o volbu „na zelené louce" — správnou odpověď obvykle určuje již existující identitní infrastruktura.
Jak SSO funguje na straně Drupalu
Na straně Drupalu je SSO řešeno prostřednictvím přispěvatelských modulů, nikoli jádra, a pro každý protokol existuje vyzrálý ekosystém. Ať už je použit jakýkoli modul, integrace zajišťuje několik zásadních úkolů: přesměrovává neověřené uživatele k IdP, přijímá a ověřuje odpověď autentizace a mapuje atributy vrácené IdP na účet Drupal.
Koncept, který stojí za pochopení, je poskytování „just-in-time" (JIT). Namísto předem vytvořeného účtu Drupal pro každého potenciálního uživatele vytváří JIT poskytování účet automaticky při prvním úspěšném ověření přes IdP a naplní jej atributy, které IdP poskytne — jménem, e-mailem a rolí. Právě to umožňuje, aby se SSO škálovalo na celou univerzitu: žádný administrátor nemusí ručně vytvářet tisíce účtů a přiřazování rolí lze automaticky řídit podle členství ve skupinách hlášeného IdP. Pro instituce, které hodnotí konkrétní moduly, dokumentují aktuální podporované možnosti oficiální projektové stránky Drupal.org pro SimpleSAMLphp Authentication, LDAP a CAS.
Správa identit: Část, kterou většina návodů vynechává
Většina tutoriálů o SSO končí ve chvíli, kdy přihlašování funguje. Pro univerzitu, která spravuje citlivá data studentů a zaměstnanců, jsou však náročnější a důležitější otázky ty, které se týkají správy: kdo má přístup, jak se přístup odebírá a kde identita skutečně žije. Právě zde se dobře navržená integrace odlišuje od té, která jen funguje.
Ústředním principem je, že by Drupal neměl vedle institucionálního poskytovatele identity udržovat vlastní oddělený soubor uživatelských účtů. Pokud lokální účty Drupal existují nezávisle, postupně se rozcházejí ze synchronizace: nejsou deaktivovány, když někdo odejde, a časem se u nich hromadí slabá hesla. Doporučeným postupem je zakázat lokální ověřování heslem pro všechny kromě jediného „záchranného" administrátorského účtu, veškeré ověřování směrovat přes IdP a přebírat vícefaktorové ověřování, zásady hesel a životní cyklus účtu instituce z tohoto nadřazeného zdroje. Jinými slovy, identitní systém instituce — nikoli Drupal — se stává jediným zdrojem pravdy o tom, kdo se může přihlásit.
Tento přístup přináší konkrétní bezpečnostní výhodu: odebrání přístupu (deprovisioning). Když student dostuduje nebo zaměstnanec odejde, deaktivace jeho centrálního identitního účtu okamžitě odstřihne jeho přístup do Drupalu spolu se vším ostatním, aniž by zůstal osiřelý lokální účet. Pro instituci odpovědnou za ochranu dat je tento jediný, centralizovaný vypínač mnohem bezpečnější než snaha dohledat samostatné účty napříč každým systémem.
Univerzitní scénáře: multisite, životní cyklus a absolventi
SSO v univerzitním kontextu přináší několik scénářů, se kterými se jednotlivé firemní stránky nikdy nesetkají:
- Jednotné přihlášení pro více stránek (multisite): Velké univerzity provozují mnoho webů — hlavní web plus samostatné stránky pro fakulty, katedry a výzkumná centra. SSO umožňuje uživateli přihlásit se jednou a plynule se pohybovat mezi všemi z nich, zatímco ověřování zůstává centralizované. To se přirozeně pojí s vícestránkovou architekturou Drupalu, kde je mnoho stránek spravováno z jednoho místa.
- Životní cyklus identity: Vztah člověka k univerzitě se v čase mění — uchazeč, student, absolvent a někdy i zaměstnanec — a s tím se mění i jeho potřeby přístupu. Odvozování rolí Drupalu z atributů IdP znamená, že přístup může tento životní cyklus automaticky sledovat, místo aby byl ručně upravován při každém přechodu.
- Odlišné skupiny uživatelů: Studenti, akademičtí pracovníci, zaměstnanci a absolventi často potřebují různé úrovně přístupu k různým systémům. Protože IdP hlásí členství ve skupinách, může Drupal automaticky přiřadit každou skupinu uživatelů k odpovídající roli a udržovat tak oprávnění v souladu se skutečným statusem uživatele.
Tyto scénáře jsou přesně důvodem, proč je integrace identit klíčovou součástí budování univerzitní platformy, a ne dodatečným nápadem. Souvisí také se širším souborem akademických integrací, které web na Drupalu obvykle potřebuje — mezi nimi i výuková platforma, které se věnujeme v našem průvodci integrací Moodle a Drupal.
Časté chyby SSO a jak se jim vyhnout
- Provozování lokálních účtů vedle IdP: Nejčastější selhání ve správě. Nezávislé účty Drupal se rozcházejí ze synchronizace, nejsou odebírány a hromadí se u nich slabá hesla. Ověřování směrujte přes IdP a lokálně ponechte pouze jeden „záchranný" administrátorský účet.
- Zapomenutí na záchranný účet: Pokud každé přihlášení závisí na IdP a ten se stane nedostupným, nikdo se nedostane dovnitř — ani administrátoři. Jediný dobře zabezpečený lokální nouzový účet zabraňuje úplnému uzamčení.
- Neuvážené mapování rolí: Automatické udělování zvýšených rolí Drupalu na základě atributů IdP může neúmyslně poskytnout administrátorský přístup. Mapujte každý atribut na nejnižší potřebné oprávnění a administrátorské role posuzujte s vyšší obezřetností.
- Ignorování odebírání přístupu: Pokud se zaměříte pouze na to, aby fungovalo přihlašování, zůstane nezodpovězena důležitější otázka — jak se přístup odebírá. Navrhujte i pro okamžik, kdy někdo odejde, nejen pro okamžik, kdy se připojí.
- Volba protokolu izolovaně: Výběr technologie SSO bez ověření toho, co instituce již provozuje, vede ke zbytečné složitosti. Vycházejte z existujícího poskytovatele identity a připojte se k němu.
- Zanedbání mapování atributů: Pokud atributy IdP nejsou správně namapovány na pole a role Drupalu, mohou se uživatelé přihlásit, ale skončí se špatnými oprávněními. Ověřte mapování atributů se stejnou pečlivostí jako samotný přihlašovací proces.
Při správném provedení dělá integrace SSO ze stránek Drupal bezproblémovou a bezpečnou součást digitálního ekosystému univerzity — jednu identitu, centrálně spravovanou, zasahující do všech propojených systémů. Jde o základní schopnost pro každou instituci provozující Drupal ve velkém měřítku a je součástí širší sady akademických integrací popsaných v našem přehledu Drupal ve vzdělávání.
Často kladené otázky o Drupal SSO
Ukládá Drupal hesla, když je SSO povoleno?
Ne — to je hlavní bezpečnostní výhoda SSO. Když je ověřování delegováno na poskytovatele identity, přihlašovací údaje uživatele ověřuje IdP a nikdy nejsou uloženy v Drupalu. Doporučená konfigurace zcela zakazuje lokální ověřování heslem, s výjimkou jediného „záchranného" administrátorského účtu vyhrazeného pro nouzové situace. To znamená, že hesla, zásady hesel i vícefaktorové ověřování se nacházejí v centrálním identitním systému instituce a Drupal jednoduše důvěřuje jeho ověřené odpovědi.
Může Drupal používat více poskytovatelů identity současně?
Ano, v závislosti na použitých modulech lze Drupal nakonfigurovat tak, aby fungoval s více zdroji ověřování. Běžným příkladem je instituce, která ověřuje studenty přes jeden systém a zaměstnance přes jiný, nebo která pro většinu uživatelů zachovává SAML a zároveň si ponechává omezenou lokální možnost pro konkrétní skupinu. S každým dalším zdrojem se konfigurace stává složitější, proto je praktickým doporučením podporovat pouze ty poskytovatele identity, u kterých existuje skutečná potřeba, a udržovat nastavení tak jednoduché, jak to skutečné požadavky instituce dovolují.
Jaký je rozdíl mezi ověřováním a poskytováním účtů?
Ověřování znamená potvrzení, kdo uživatel je — ověření jeho přihlašovacích údajů vůči poskytovateli identity. Poskytování účtů (provisioning) znamená vytváření a udržování uživatelova účtu a atributů v Drupalu. SSO se stará o ověřování; poskytování typu just-in-time se stará o následné vytvoření účtu, který se automaticky vygeneruje při prvním přihlášení a naplní se atributy z IdP. Oba procesy spolupracují: ověřování prokazuje identitu a poskytování dává této identitě místo a roli v rámci Drupalu.
Je pro univerzitu lepší SAML, nebo CAS?
Ani jedno není univerzálně lepší — záleží na tom, co vaše instituce již provozuje. SAML, včetně jeho akademické implementace Shibboleth, je správnou volbou pro instituce zapojené do výzkumných federací nebo standardizované na identitních platformách, jako je Entra ID nebo Okta. CAS je silnou volbou pro univerzity, které již provozují kampusový server CAS. Rozhodnutí by se mělo řídit existující identitní infrastrukturou spíše než abstraktním žebříčkem: připojte Drupal k systému, kterému vaše instituce již důvěřuje, a nechte to určit protokol.