Organizační struktura

V aplikaci dovolujeme definovat více druhů stromových struktur přes agendu typů a prvků stromové struktury. Tyto stromové struktury se používají napříč aplikací viz dále.

Při editaci typu stromové stuktury lze definovat výchozí typ, který bude použit jako organizační struktura v aplikaci (taková zkratka) a také výchozí prvek organizační struktury, který bude použit pro vytváření výchozího pracovně právního vztahu (PPV, viz dále).

Organizační struktura má vlastní místo v hlavním menu. V agendě organizační struktury lze procházet prvky struktury i uživatele, kteří jsou přes PPV navázáni na organizační strukturu. V agendě se zobrazují pouze uživatelé mající k danému typu struktury vztah ⇒ mají PPV v organizační struktuře.

Definují vazbu identity na stromovou strukturu. V aplikaci razíme logiku, že každá identita má minimálně jeden PPV. Proto je každé identitě při jejím vytvoření automaticky vytvořen jeden výchozí PPV dle konfigurace výchozí organizační struktury (viz. výše). Pokud je ve výchozí organizační struktuře vybraný i výchozí prvek struktury, tak je při vytváření výchozího PPV použit ⇒ identita je "posazena" na danou výchozí pozici v organizační struktuře. Pokud není vybraný výchozí prvek struktury, je identita "posazena" na pozici s názvem "Default" bez zařazení do organizační struktury.

PPV hraje důležitou né-li hlavní roli při přiřazování rolí identitě - role se vždy přiřazuje na PPV nikoli přímo na identitu. Tím je zajištěno, že vyhodnocení oprávnění půjde vždy jednou cestou přes PPV, kde může figurovat stromová (organizační) struktura ⇒ oprávnění mohou býti vztažena přes tyto struktury / pozice v organizaci.

Další chtěnou funkční vlastností je, že při zániku / zrušení PPV zaniknout i všechny role z tohoto vztahu vycházející. Na periodickou kontrolu neplatných PPV je vytvořena plánovatelá úloha IdentityContractExpirationTaskExecutor. Není nutné úplně smazat PPV, aby zanikly přiřazené role. Je možné PPV nastavit jako neaktivní, tím dojde ke zrušení rolí také - někdy je fajn vědět, že identita měla nějaký vztah k organizaci.

Přes PPV jsou v agendě prvků stromové struktury / organizační struktuře dohledáváni uživatelé, kteří jsou na vybraný prvek "posazeni". V agendě se zobrazují pouze uživatelé mající k danému typu struktury vztah ⇒ mají PPV s vybraným typem.

Dohledání vedoucích dle PPV

Dle PPV se dají dohledat vedoucí dvojím způsobem:

  • Vedoucím je ta identita, která má nastaven PPV na nadřezeném prvku ve stromové struktuře
  • Vedoucím je ta identita, které je nastavena přímo u PPV (garant). U PPV může býti nasteveno více vedoucích.

Pro možnost přetížení dohledání vedoucích na různých prostředích (pokud by nestačili možnosti výše) byla vytvořen samostatný filtr SubordinatesFilter. Její defaulntní implementaci je možné podědit nebo vyměnit. SubordinatesFilter konstruuje subdotazy na podřízené a obráceně na vedoucí, které jsou použity pro vyhodnocení napříč aplikací (autorizační politiky, filtry).

Pro efektivní dotazování nad stromovou strukturou byla vytvořena samostatná knihovna ForestIndex, která buduje vedle stromové struktury index, který přináší výhody:

  • možnost dotázat se na všechny děti libovolného prvku stromu jedním dotazem (všechny děti směram dolů)
  • možnost dotázat se na všechny rodiče libovolného prvku stromu jedním dotazem

Dokumentace a příklad zapojení do projektu je uvedena zde.

Vyhledávní přes index je zapojeno na:

  • Vyhledávání identit dle organizační struktury (přes PPV)
  • Zobrazení pozice identity v organizační struktuře

Pro rebuild indexu byla vytvořena úloha RebuildTreeNodeIndexTaskExecutor, kde je nutné zadat kód struktury, která má býti přeindexovaná.

Role přidělované na základě zařazení v organizační struktuře. Každá identita v CzechIdM má implicitní vztah (~PPV), který je svázán s prvkem organizační struktury.

Každý kdo má právo editovat roli může tuto roli přiřadit k prvku libovolné organizační struktury. Toto přiřazení/odebrání podléhá schvalování stejným způsobem jako by danou roli dostával běžný uživatel. Schválení přiřazení role k organizační struktuře způsobí jakési "předschválení" pro všechny uživatele zařazené do org. struktury. Přidělení role uživateli poté už nebude vyžadovat schvalování (je přece schválena už pro organizační jednotku ve které je uživatel).

Zobrazení informací o automaticky přidělovaných rolích

Zobrazení informací o rolích navázaných na organizační strukturu bude minimálně na následujících místech:

  • V detailu prvku struktury bude vidět seznam rolí, které jsou k němu přiřazené
  • U role bude vidět seznam prvků struktury (celá cesta ve stromu) pro které je tato role použita pro automatické přidělení uživateli
  • U uživatele bude vidět v seznamu přidělených rolí, že danou roli dostal automaticky

Dědičnost přiřazení rolí

Pokud je role přiřazena k nějakému prvku organizační struktury, je možné následující chování:

  A
  |
  B
 / \
C   D
   / \
  E   F
  • Role je přidělena uživateli, který má vazbu přesně na tento konkrétní prvek org. struktury
    • Pokud roli navážu na "B", tak automaticky dostane roli každý uživatel, jehož úvazek je přiřazen právě k "B".
  • Role je přidělena všem uživatelům, kteří mají vazbu na tento prvek org. struktury a na celý podstrom (od kořene směrem k listům)
    • Dědičnost je v celém podstromu bez omezení hloubky
    • Pokud roli navážu na "B", tak roli automaticky dostane každý uživatel, jehož úvazek je přiřazen k "B", ale také pokud je v "C", "D", "E", "F".
  • Role je přidělena všem uživatelům, kteří mají vazbu na tento prvek org. struktury a na všechny nadřazené (tj. směrem od uzlu ke kořenu).
    • Toto chvoání umožní přidělit role podle scénáře "vše co má podřízený musí mít automaticky nadřízený". Takže navázáním role na "B" se automaticky přiděluje role uživatelům s úvazkem v "A"
    • Máme minimálně jednoho zákazníka, kde je toto používáno
    • Nyní nebudeme implementovat, ale je zde uvedeno z důvodu případného rozmyšlení možností zda a jak to řešit

Audit

Všechny změny v přiřazení rolí k organizační struktuře budou auditovány. V auditním logu bude minimálně uvedeno:

  • Informace o tom, že změna v rolích byla provedena na základě aplikace automatického pravidla a jakého konkrétního
  • Reference na proces ze kterého změna vzešla, aby šlo identifikovat že se to stalo v rámci synchronizace nebo uložení z webu…

Změna rolí u uživatele

K aktualizaci (přidání a odebrání) automaticky přidělovaných rolí dochází u identity minimálně v následujících případech:

  • Při každém uložení změny v org. zařazení
    • Vztah (případně více vztahů) identity je navázán na organizační strukturu. Pokud je na prvek v organizační struktuře přiřazena nějaká role (více rolí), uživatel má tyto role dostat automaticky.
  • Při každém uložení změny ve vazbě role-org. struktura
    • Pokud je role navázána na nějaký prvek organizační struktury, je třeba přepočítat role na identitách, které jsou navázané skrz vztah k danému prvku org. struktury.
  • Automatické přidělení rolí uživateli není schvalováno a je hned realizováno.

Implementační detaily

  • Konfigurace a přidělování automatických rolí je implementováno dle popisu výše
  • Schvalování konfigurace automatických rolí (přidání, odebrání) je konfigurovatelné. Celá implementace je v rámci procesorů, které je možné vypnout či vyměnit definici workflow (viz. konfigurace aplikace). Pro schvalování jsou připraveny výchozí definice workflow, kde přiřazení i odebrání konfigurace automatické role schvaluje garant role (první vyhrává, pokud jich je více), pokud není sám původcem operace (pak se neschvaluje a je rovnou provedeno).
  • Úprava automatické role není implementována ⇒ algoritmus "drop and create". Může být doplněno v budoucnu.
  • Schvalování samotného přiřazení role identitě dle konfigurace automatické role není implementováno - závisí na aktuálně vyvíjené funkcionalitě žádostí o role - bude zapojeno posléze.
  • auditní stopa bude implementována v budoucnu
  • Pokud je smazána automatická role, jsou smazány všechny přiřazené role z této automatické role vyplývající.
  • Pokud je přidána nová automatická role, je tato role přiřazena všem stávajícím identitám s exitujícím PPV, který by měl roli dostat, realizace je skrze Long running task.
  • Pro Role které mají začátek platnosti v budoucnu bude account management proveden až při splnění validity.
  • Práce s platnostmi PPV:
    • Při změně platnosti kontraktu jsou změny promítány do platností automaticky přiřazených rolí
    • Pro kontrakty jsou připraveny automatické role i s budoucí platností
    • Pro neplatné kontrakty (v minulosti) nejsou automatické role přiděleny. Při změně platnosti do minulosti nejsou role rovnou odebírány, pouze se synchronizují datumy. O samotné odebírání vypršelých rolí a rolí u vypršených kontraktů se starají samostatné dlouhostvající úlohy (IdentityRoleExpirationTaskExecutor, IdentityContractExpirationTaskExecutor). Dlouho trvající úlohy jsou vázány pouze na platnosti kontraktů ⇒ atribut disabled se pro ně tváří jako popisný atribut. Vypršené role a role u vyplšených kontraktů se neaplikují při přihlášení.
  • Přepočítávání automatických rolí při změnách stromových struktur (přesuny prvků) nejsou prozatím řešeny (comming soon).