Schvalování v CzechIdM

V následujícím textu se snažím zevrubně popsat problematiku okolo schvalování v kontextu správy identit pomocí CzechIdM. Nejdříve vysvětlím, co pojmem “schvalování” myslím a také uvedu pár výhod, které přináší použití správce identit. Poté se podíváme na tuto problematiku očima uživatele a administrátora CzechIdM. Později se dostanu i k tomu, jak je schvalování v našem systému realizováno.

Schvalovací proces

Schvalovací proces v CzechIdM je elektronická obdoba procesu běžného třeba na úřadech. Pokud něco chcete, musíte o to požádat. Vaše žádost je poté doručena k vyřízení člověku, který má schvalování na starosti. Ten rozhodne, zda vaší žádost schválí, nebo zamítne. V případě první možnosti je vám následně předáno to, o co jste žádali. Na úřadech (a v mnoha firmách) jsou tyto žádosti v papírové podobě, a tudiž se může snadno stát, že je doručena ke špatnému člověku nebo úplně ztracena. Je-li schvalovací proces řešen emailovou komunikací, hrozí, že ji člověk v záplavě jiných emailů ztratí. Navíc je i tato forma přenosu informací relativně nebezpečná (kdokoliv ji může přečíst). Pokud k výše zmíněnému přičteme i to, že akce a rozhodnutí kolem žádostí nejsou nikde zaznamenávany, je jasné, že tyto způsoby nejsou zdaleka ideální.

Lepší způsob schvalování nabízí CzechIdM. Výhody jsou především:

• Rychlost – vaše žádost je okamžitě doručena schvalovateli. Pokud ten na ni nebude reagovat po definovanou dobu, je možné žádost přeposlat na někoho jiného.
• Bezpečnost – informace v žádosti vidí pouze schvalovatel. Emailem jde pouze informace o tom, že žádost byla podána a odkaz na ni. Před jejim zobrazením je ovšem vyžadována autentizace.
• Dohledatelnost – podání žádosti, rozhodnutí schvalovatele i to, zda vám bylo “dáno” to, o co jste si žádali, je zaznamenáváno. Je tedy například možné kdykoliv zjistit, kdo, kdy a jak rozhodl ohledně schválení žádosti.

 

Pohled uživatele

Uživatelem je v tomto případě myšlen jak žadatel, tak schvalovatel. Žadatel si po přihlášení do uživatelského rozhraní může například požádat o roli, která ho bude opravňovat k přístupu do nějakého systému. Třeba do systému účetnictví. Jelikož tento systém obsahuje informace, které nemůže vidět kdokoliv, podléhá vytvoření účtu v systému schválení hlavní účetní. Té tedy přijde email, že má schválit přístup. Proto se přihlásí do CzechIdM a zobrazí si detail žádosti. Poté, co klikne na tlačítko schválit, je žadateli okamžitě vytvořen účet.

Pohled administrátora

Administrátor má na rozdíl od obyčejného uživatele přístup do administračního rozhraní. Díky tomu je schopen provádět mnohem více operací. K těm, které se týkají schvalovacího procesu patří:

• Vytvoření role, jejíž vlastnictví opravňuje ke schvalování.
• Přiřazení této admin role nějakému uživateli. Tím se z uživatele stává schvalovatel (který ale ještě nemá nic na schvalování).
• Konfiguraci role tak, aby její přiřazení vyžadovalo schválení. U role se definují schvalovatelé. Od té chvíle jim budou chodit ke schválení žádosti o konfigurovanou roli.

Nyní si tyto operace popíšeme podrobněji. V CzechIdM není žádná výchozí role, která by definovala schvalovatele. Jeji vytvoření je ale velmi jednoduché. Na záložce “Role” klikneme na tlačítko “Nová admin role”. Vyplníme libovolné jméno a na záložce “Oprávnění” vybereme “ROLE” a zaškrtneme “APPROVE”. Roli můžeme samozřejmě přidat i další oprávnění, definovat její podrole nebo systémy, na kterých přiřazuje účet. Kliknutím na tlačítko “Uložit” roli vytvoříme.

Nyní můžeme vytvořenou roli přiřadit uživateli, ze kterého chceme udělat schvalovatele. V menu na záložce “Uživatelé” vyhledáme tohoto uživatele a klikneme na odkaz editovat. Zobrazí se editační formulář. Přejdeme na záložku “Role a kontrolované organizace” a přidáme námi vytvořenou roli. Také vybereme organizaci, pro kterou budou všechny admin role uživatele platit. Po klepnutí na tlačítko “Uložit” dojde k vytvoření schvalovatele.

Zbývá u nějaké role určit schvalovatele. Opět tedy přejdeme na záložku “Role” a vyberem roli, jejiž přiřazení komukoliv budeme chtít nejdříve potvrdit schvalovatelem. Uděláme tak na záložce “Schvalovatelé” v detailu role. Pro vyhledání schvalovatele můžeme použít filtr. Pokud chcete zobrazit všechny, tak nechte vyhledávací pole prázdná a klepněte na tlačítko “Vyhledat”. Zobrazí se všichni uživatelé, kteří mají roli s oprávněním schvalovat. Některé z nich vybereme a roli uložíme. Tím je nastavení schvalovatele hotovo. Důležité je ještě to, že pokud definujeme více schvalovatelů u jedné role, pak každému z nich dojde při pokusu o přiřazení role požadavek na schválení. Kdo první schválí, ten vyhrává. Ostatním pak takový požadavek zmizí.

Pohled vývojáře

Schvalovací procesy jsou z části implementovány v Java kódu a z části pomocí workflow. Schvalovací formuláře samozřejmě též využívají i JSF. V následujícím textu popíšeme, jak jsou jednotlivé části provázány a jak spolu komunikují. I když se schvalování může týkat i jiných událostí, my si to, jak je schvalování implementováno, ukážeme na příkladu schválení přiřazení role.

Celý proces začíná voláním “Data.checkinView” na “UserView”, do jehož uzlu “roles” byla přidána role vyžadující schválení. Takovéto view se dostane přes třídy “Data” a “UserManagementBean” až do objektu třídy “UserViewHandler”. Zde se zjistí, že byla přidána role a že má tato role určené schvalovatele. K těmto operacím dochází v metodě “processViewRolesAttribute” a z ní volané “startRoleApproveWfsIfNeeded”. Druhá z uvedených metod pak také spouští workflow “user.role.approve”, které notifikuje schvalovatele a vytváří schvalovací požadavek.

Toto workflow tedy obsahuje uzel typu “task-node”. V okamžiku, kdy se běh programu dostane do tohoto uzlu, je vytvořen “task” (schvalovací požadavek, úkol) s následujícími proměnnými (žádná z nich není povinná, ale doporučujeme vyplňovat alespoň “approvers”, “approvalInfo”, a “pageId” nebo “workflowName”):

• approvers – seznam schvalovatelů
• roleName – název role, která se schvaluje
• userView – view uživatele, kterému má být role přidána
• pageId – id stánky, která se má použít pro zobrazení tohoto úkolu. V případě schvalování rolí to je “include/roleApprove”
• workflowName – název workflow, která bude mít na starosti zobrazení uživatelského požadavku. Pokud je nastavena tato proměnná (a není null), tak zastíní i případně nastavenou proměnnou “pageId”. Použití nachází v případě složitějšího zpracovávání požadavku, kdy nevystačíme s pouhým zobrazením stránky následovaným rozhodnutím o schválení
• approvalInfo – informace o schvalování, které se použijí pro záznam do audit logu. K tomu dochází po ukončení požadavku ve workflow “userTask.detail”. Je možné doplnit položky “targetIdentityName”, “newValue”, “oldValue”, “operationSubject”, “detail”

Proměnné jsou poté dostupné ve view daného tasku. Tím, že je vytvořen task, dojde k přerušení workfow. Běh programu se vrací do java kódu, kde dochází k uložení stavu workflow do databáze. Dále program pokračuje kódem v “UserViewHandleru”, což může znamenat další spuštění workflow pro jinou přidanou roli. Workflow zůstáva přerušeno do doby ukončení schvalovacího požadavku (schválení, nebo zamítnutí).

Schvalovateli byl ve workflow “user.role.approve” poslán email o tom, že na jeho schválení čeká požadavek o přiřazení role. Přihlásí se do uživatelského rozhraní IdM a přejde na stránku s úkoly. Tím se spouští workflow “ui.userTask.list”, které vytáhne z repository všechny neukončené úkoly přihlášeného uživatele. V administračním rozhraní je, pro získání všech úkolů, používáno workflow “userTask.list”. To zatím dělá téměř to stejné, co workflow z uživatelského rozhraní. Dá se ale předpokládat, že časem bude jeho funkcionalita rozšířena tak, aby si administrátor s dostatečnými právy mohl vylistovat úkoly i jiných uživatelů. Pak již se tato dvě workflow budou velmi lišit. Nyní je rozdíl pouze ve formulářích, které zobrazují. Jedná se buď o “user/userTask/userTasks” pro uživatelské rozhraní nebo “admin/userTask/userTasks” pro administrační rozhraní. Formuláře jsou opět velmi podobné, ale i u nich to v budoucnu nebude platit.

Po kliknutí na název úkolu je spuštěno workflow “userTask.detail”. To si nejdříve obstará kompletní view úkolu s daným id. Poté spustí akci “eu.bcvsolutions.idm.app.workflow.ShowUserTaskPageAction”, která z předaného pohledu zjistí, kterou stránku má použít pro zobrazení úkolu. Zjišťuje to na základě proměnné “pageId”. Pokud není definována, je použita výchozí stránka “/adminOrUser/userTask/detail.xhtml”, která nedělá nic jiného, než že zobrazí všechny proměnné zobrazovaného úkolu v tabulce. Pokud je proměnná “pageId” definována, tak je naopak zobrazena stránka, jejíž id je hodnotou proměnné. Ve skutečnosti je ale stránka nejdříve vložena do “/adminOrUser/userTask/customDetail.xhtml” a ta je pak zobrazena.

Workflow “userTask.detail” čeká během zobrazování stránky v uzlu “showPage”. Z něho vedou následující přechody, jimž mohou odpovídat tlačítka na formuláři:

• finishAndSave – ukončí úkol, aniž by došlo ke schválení nebo zamítnutí
• save – uloží změny v úkolu. Úkol ale tímto není ukončen a stále bude zobrazován v seznamu aktivních úkolů
• reset – znovu načte view úkolu
• close – neuloží změny v úkolu, ani ho neukončí
• approve – nastaví proměnnou “___IS_TASK_APPROVED___” na hodnotu “true” a poté ukončí a uloží úkol
• deny – chová se stejně jako přechod “approve” s tím rozdílem, že nastaví hodnotu proměnné na “false”

Proměnnou “___IS_TASK_APPROVED___” kontroluje UserTaskManagementBean, který je volán z workflow prostřednictvím “Data.checkinView”. Pokud je nastavena, tak podle její hodnoty použije přechod “approved”, nebo “denied” z “task-node”. Jedná se o uzel ve workflow, které je asociované s právě ukončeným taskem. Tím se běh programu dostává zpět do workflow, které úkol vytvořilo a bylo tedy až do tohoto okamžiku pozastaveno.

Pokud je místo “pageId” použito “workflowName”, tak v uzlu “userTask.detail” dojde ke spuštění v proměnné uvedeného workflow. Tomu je do kontextu přidána proměnná “taskView” s pohledem na aktuálně zpracovávaný požadavek. Očekává se, že workflow před ukončením nastaví proměnnou “stateResult”. Její hodnotou by mělo být taskView. Pokud bude v TaskView atribut nextAction, tak se jeho hodnota použije pro navigaci do dalšího uzlu workflow “userTask.detail”. Hodnota tedy odpovída názvu přechodu, které jsou uvedeny výše v seznamu.

Příklad vytvoření schvalovací úlohy ve workflow

Následující kód vytvoří schvalovací požadavek a pozastaví workflow, ve kterém se nachází. Jakmile dojde ke schválení, nebo zamítnutí, běh workflow bude pokračovat buď přechodem do uzlu “addRole”, nebo do uzlu “logDisapproval”.

<task-node name="createUserTask">
  <task name="SchvaleniPridaniRole">
    <assignment pooled-actors="#{approvers}"></assignment>
    <controller>
      <variable name="approvers" access="read"/>
      <variable name="roleName" access="read" />
      <variable name="userName" access="read" />
    </controller>
    <description></description>
  </task>
  <transition name="approved" to="addRole"/>
  <transition name="denied" to="logDisapproval"/>
</task-node>

Závěr

V článku bylo z různých úhlů pohledu popsáno schvalování tak, jak je chápáno v CzechIdM.  Jeho nasazení přináší výhody v podobě rychlosti, bezpečnosti a dohledatelnosti. Samotná implementace schvalovacího procesu se může zdát složitá. To ale vývojáře workflow nemusí trápit, protože do implementace nemusí zasahovat. Pouze ve workflow vytvoří uzel správného typu a případně formulář pro zobrazení požadavku. O zbytek se postará CzechIdM.

Další témata