Project

General

Profile

Actions

Task #2687

closed

Implement support for SSO and SLO against CAS

Added by Roman Kučera almost 4 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Radek Tomiška
Category:
Authentication / Authorization
Target version:
Start date:
02/15/2021
Due date:
% Done:

100%

Estimated time:
24.00 h
Owner:

Description

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.


Related issues

Related to IdStory Identity Manager - Task #914: Add property with FE and BE urlClosedRadek Tomiška01/17/2018

Actions
Related to IdStory Identity Manager - Task #2984: FE: Stay on log out page (configurable)ClosedRadek Tomiška10/19/2021

Actions
Actions

Also available in: Atom PDF