Task #2687
Updated by Petr Fišer over 2 years ago
*Ticket task:*
Changing ticket task after discussion with Vítek. Written in czech for clarity, english version will follow soon.
Original ticket task is mentioned at the bottom.
Integrace IdM-CAS
Standardní integrace viz https://apereo.github.io/cas/6.2.x/protocol/CAS-Protocol.html (Web flow diagram).
UC1:
# Uživatel přichází na IdM, nemá CIDMST token.
# IdM ho přesměruje na CAS k přihlášení.
# Uživatel se přihlásí "do CASu", CAS ho přesměruje zpět na IdM s tokenem.
** Pokud uživatel už je "do CASu" přihlášený, není přihlášení požadováno a dojde rovnou k přesměrování uživatele.
# IdM si token ověří v CASu (přímá komunikace IdM->CAS) a získá si i atributy uživatele.
# Na základě obdržených atributů vydá IdM uživateli svůj CIDMST token a dále se pracuje už jen s ním.
UC2:
# Uživatel přichází na IdM, má CIDMST token.
# Pokud token není platný, tak viz výše (jako by token neexistoval).
# Pokud je token platný, s CASem se nijak neinteraguje.
UC3:
# Odhlašovací button v IdM vyvolá odhlášení z IdM i CASu.
UC4:
# Uživatel klikne na "přihlášení jako jiný uživatel".
# IdM použije svou interní funkcionalitu a nijak do toho nezapojuje CAS.
# Uživatel je v IdM nyní přihlášen jako jiný uživatel.
UC5:
# Uživatel klikne na odkaz v mailu, který vede na konkrétní stránku v IdM.
# Pokud má uživatel platný CIDMST, projde do IdM a tma normálně pracuje jako to teď je.
# Pokud uživatel nemá platný CIDMST, je přesměrován na CAS k přihlášení.
# Po přihlášení je uživatel (ve finále) přesměrován na konkrétní stránku v IdM, na kterou se původně snažil z mailu prokliknout.
Nahromadilo se poměrně velké množství feedbacku na aktuální řešení v produktovém RM: #22187, #22102, #22129, #22398, #22409, #22410.
Výcuc ve formě nefunkčních požadavků:
* IdM zobrazuje rozumné chybové hlášky, když se něco nepodaří.
* IdM se při chybě ověření CAS tiketu nesnaží uživatele poslat na CAS znovu.
** Pokud CAS vrátí korektní odpověď (byť o tom že token není platný), tak nejde o "chybu ověření tiketu".
** Ověření tiketu IdM->CAS musí být schopno přežít transientní síťové chyby (-> něco jako několik oddělených pokusů, pokud předchozí skončily na chybě sítě). IdM nesmí zkoušet do nekonečna.
* CAS nepodporuje anchory v URL, které IdM používá jako routy pro frontend. Je potřeba to zohlednit.
** Myšlenka: Co celý handling externí autentizace (ať jde o CAS, Kerberos s REMOTE_USER hlavičkou, aj.) přesunout pouze na backendový endpoint?
* Aplikační účty přistupující do IdM pomocí apikey/CIDMST tokenu (např. password filter) jsou lokální k IdM a nepodléhají autentizaci CASem.
* IdM audituje přihlášení uživatele z externí autentizace ve svém aplikačním logu.
** Mělo by asi jít o audit přeměny CAS tiketu na CIDMST, vč. třeba loginu z IdM a loginu z CASu.
** Service tiket je možné v logu uvést, protože má jen krátkou platnost.
* Alespoň rámcově mrknout, kolik validací service tiketu je potřeba... víme, že v současném řešení si Chrome/FF/Opera vystačí s jednou, IE/EDGE jich potřebují klidně 100.
** Pokud bychom řešili externí autentizaci čistě na backendu, asi by se to tím "vyřešilo samo".
* Podporovat režim pro explicitní přihlášení administrátora, pokud je zapojeno SSO.
** Je otázka, zda je to jen vzhledem k CASu protože jsme to částečně potkali i s Kerberem - asi na analýzu, proto přidávám sem a kdyžtak vyhodíme. Existuje k tomu nedořešená diskuze v tiketu #22410.
** Případně je to další UC, který musíme vydefinovat.
* CAS integraci produktu musí jít konfiguračně zapnout pomocí application properties. By-default bude vypnutá.
** Konfigurace bude řešena také pomocí application properties. Lze se inspirovat u stávajícího idm-cas modulu. Sada properties je tam vyhovující, ale chtěli bychom u nich vylepšit celkový handling.
** Konfigurace musí podporovat i setup, kdy je CAS na úplně jiném serveru.
* Implementace musí pokrývat vše, co na úrovni frontendu obsahuje stávající řešení.
** Neměl by být problém, stávající řešení je podmnožinou specifikace výše.
** Cilem je ze stavajícího idm-cas modulu zahodit celou frontendovou část, aby se při relinku aplikace na prostředí zákazníka mohl přesočit build frontendu a volali jsme jen přebalení backendu.
*Old ticket task (up to #note-11):*
The main point of this ticket is to implement feature for SSO and SLO against CAS.
The flow will be
* access URL where IdM is running
* if user is not authenticated redirect to CAS login page
* login
* user is redirect back to IdM.
* user is authenticated
On BE we will implement filter.
On FE we will implement login in Login and Logout page.
This feature needs to be disabled be default.