IdStory Identity Manager

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:

1. Uživatel přichází na IdM, nemá CIDMST token.
2. IdM ho přesměruje na CAS k přihlášení.
3. 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.
4. IdM si token ověří v CASu (přímá komunikace IdM->CAS) a získá si i atributy uživatele.
5. 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:

1. Uživatel přichází na IdM, má CIDMST token.
2. Pokud token není platný, tak viz výše (jako by token neexistoval).
3. Pokud je token platný, s CASem se nijak neinteraguje.

UC3:

1. Odhlašovací button v IdM vyvolá odhlášení z IdM i CASu.

UC4:

1. Uživatel klikne na "přihlášení jako jiný uživatel".
2. IdM použije svou interní funkcionalitu a nijak do toho nezapojuje CAS.
3. Uživatel je v IdM nyní přihlášen jako jiný uživatel.

UC5:

1. Uživatel klikne na odkaz v mailu, který vede na konkrétní stránku v IdM.
2. Pokud má uživatel platný CIDMST, projde do IdM a tma normálně pracuje jako to teď je.
3. Pokud uživatel nemá platný CIDMST, je přesměrován na CAS k přihlášení.
4. 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.