Tento dokument popisuje, jak bezvýpadkově přemigrovat Shibboleth IdP z jednoho serveru na jiný, aniž by si toho uživatelé všimli. Zároveň není potřeba žádné spolupráce s operátorem federace, protože nedochází ke změně metadat (čili ani certifikátů v metadatech).
Využijete toho např. v situaci, kdy chcete migrovat ze starší verze operačního systému na novější.
Pro lepší orientaci v textu zavedeme následující konvenci.
idp.example.org192.0.2.102001:db8::10idp.example.orghttps://idp.example.org/idp/shibboleth192.0.2.202001:db8::20idp.example.orghttps://idp.example.org/idp/shibboleth
Nainstalujeme a nakonfigurujeme nový server jako kdyby se jednalo o stávající server idp.example.org.
Při konfiguraci Shibboleth IdP na novém serveru použijeme entityID stávajícího serveru, tedy https://idp.example.org/idp/shibboleth, použijeme také stávající „ceritifikáty“ (ve skutečnosti páry veřejných a odpovídajících soukromých klíčů) idp-encryption.{crt,key} a idp-signing.{crt,key}, které se standardně nachází v adresáři /opt/shibboleth-idp/credentials/. S největší pravděpodobností můžeme zapomenout na „certifikáty“ takzvaného backchannelu, tedy backchannel.{crt,p12}, jelikož ho v dnešní době již téměř nikdo nepoužívá.
Samozřejmostí je identická konfigurace např. atributů (attribute-resolver.xml), ale i pravidel jejich uvolňování (attribute-filter.xml) a tak dále. Nezapomeneme ani na přenos databáze s persistentními identifikátory a samozřejmě použít stejnou sůl!
Velice vhodné je v metadatech nově nainstalovaného serveru (/opt/shibboleth-idp/metadata/idp-metadata.xml) změnit certifikáty za ty původní. To pro případ, že byste chtěli metadata někomu poskytnout, tak aby se tam nacházely ty správné (původní) certifikáty a ne špatné (nově vygenerované při instalaci, které jste přepsali původními).
Nyní si vše otestujeme pomocí jednoduchého triku. V konfiguračním souboru /etc/hosts (Linux, BSD, macOS) na naší pracovní stanici si upravíme DNS následujícím způsobem:
192.0.2.20 idp.example.org 2001:db8::20 idp.example.org
Tím jsme docílili toho, že při zadání adresy https://idp.example.org do webového prohlížeče budeme ve skutečnosti komunikovat s novým serverem, kterému jsme v DNS zatím nedali žádné jméno. Jelikož tento server zná privátní klíče k veřejným klíčům uvedených v metadatech federace, bude vystupovat v rámci federace jako stávající server idp.example.org.
Tento trik funguje, protože již není potřeba používat „backchannel“ a veškerá komunikace (přihlášení, atributy, …) funguje pomocí cookies webového prohlížeče.
Můžeme se tedy přihlásit na libovolnou službu ve federaci a otestovat, zda služba funguje správně i s nově nakonfigurovaným IdP.
Po úspěšném otestování můžeme přistoupit k samotnému přepnutí. To provedeme ve třech krocích pomocí změn DNS záznamů:
idp.example.org na co nejnižší hodnotu, která je možná, abychom dokázali přepnout uživatele co nejrychleji po vypršení platnosti nakešovaných DNS záznamů. Nyní vyčkáme, až se staré nakešované DNS záznamy nahradí novými záznamy.idp.example.org na idp-old.example.org a nový server následně pojmenujeme jako idp.example.org. TTL ponecháme na snížených hodnotách, abychom se v případě potřeby mohli změnou DNS záznamů vrátit zpět a používat i nadále IdP na původním serveru. Ten, kdo má stále nakešované staré DNS záznamy, se připojí na staré IdP, přihlásí se a vše funguje. Ten, kdo má již nové DNS záznamy, se připojí na nové IdP, přihlásí se a také vše funguje.idp-old.example.org a alokovaných IP adres) můžeme zrušit. Samozřejmostí je také odebrání záznamů z /etc/hosts pro doménu idp.example.org.Máte-li virtualizační platformu a přidělujete-li IP adresy serverům na základě MAC adres, je proces přepnutí ještě jednodušší.