Table of Contents

FIXME This page is not fully translated, yet. Please help completing the translation.
(remove this paragraph once the translation is finished)

Systémy

Napojení a správa systémů slouží ke dvěma účelům a to

Systémy je tak možné rozdělit na zdrojové, tedy ty ze kterých čerpáme data do CzechIdM a spravované (koncové), do těch data z CzechIdM plníme. Jeden napojený systém je možné využít k získávání i propagaci dat zároveň. Například personální systém, ze kterého čerpáme data o zaměstnancích, ale zpět propisujeme email a login generovaný v CzechIdM.

Napojení systému

Konfiguraci napojení systému zahájíme na záložce Napojené systémy.Zde vybereme základní informace jako:

Následně je potřeba na záložce Konfigurace vybrat konektor, kterým se vybraný systém napojí. Samotné nastavení konfigurace napojení systému se pak vždy liší podle zvoleného konektoru.

Mezi základní poskytované konektory patří:

Další konektory lze libovolně doplňovat buď z volně dostupných zdrojů (AD a Exchange konektor), vlastní implementací nebo poptávkou dodavatele CzechIdM. Konektory využívají široce rozšířený framework connId dříve openICF Connector Framework. Systém konektorů zajišťuje napojení na systém bez nutnosti úpravy samotného spravovaného systému. Využívány jsou totiž jejich standardní poskytovaná rozhraní.

Konektory

Doplnit tabulku podporovaných konektorů

Schémata

Schéma reprezentuje seznam atributů nějakého objektu v napojeném systému. Vyjmenováním atributů do schématu systému dáváme možnost CzechIdM řídit jejich načítání či plnění. Schéma pro systém nalezneme na záložce Napojené systémy, kde vybereme požadovaný systém a v detailu systému zvolíme záložku Schéma systému.

První možností je vygenerovat schéma systému automaticky, pro to slouží tlačítko Generovat schéma. Tato volba zajistí načtení všech dostupných atributů tak, jak je CzechIdM dostane od použitého konektoru. Automatické generování je možné pouze, pokud ho podporuje konektor, který jsme daná systém zvolili. Ze standardních konektorů tuto funkci podporují například Database Table connector a LDAP connector.

Další možností je naklikat spravované objekty a jejich atributy ručně.

Následně postupujeme po jednotlivých atributech, které pro práci potřebujeme.. U všech vyplníme jejich názvy na systému a jejich datové typy. Dále je u každého z napojovaných atributů zvolit některé z následujících nastavení:

Napojené atributy schématu jsou pak vidět v tabulce, jako v následujícím příkladu:


Obrázek 18: Napojené atributy schématu

Kliknutím na znak lupavedle názvu atributu získáme pohled do detailu atributu na daném schématu. Máme zde možnost nastavit následující volby:

Mapování

Dalším krokem na nastavení mapovaní atributů schématu z předchozí kapitoly.

V první řadě vybereme, pro jaký účel bude mapování sloužit, možnosti máme dvě:

Dále je potřeba zvolit, který z nastavených typů objektů chceme pro mapování zvolit. V příkladu tedy vybíráme vytvořené schéma objektu user.

Dále vybereme typ entity v CzechIdM, která bude mapovaná data obsahovat. Může se jednat následující:

Obrázek 19: Základní nastavení mapování

Nyní přejdeme k samotným atributům objektu, které chceme v nastavovaném mapování využít.

U každého mapovaného atributu máme k dispozici několik možností nastavení.

Strategie plnění,kde vybíráme z následujících možností:

Další možnosti namapovaného atributu jsou:

Zejména je třeba vybrat, zda se atribut bude mapovat na některý ze standardních atributů zvolené entity, nebo zda se jedná o doplněný rozšiřující atribut. Více o rozšířených atributech je posáno v **této kapitole**.Následně vybereme daný atribut v CzechIdM, se kterých cheme atribut systému namapovat.

Obrázek 20: Tabulka namapovaných atributů

Synchronization

Synchronizace slouží k získání dat z napojeného systému do CzechIdM. Synchronizace standardně reaguje na změnu určeného časového atributu.

Během procesu synchronizace, je pro každý účet vyhodnocena situace, ve které se vzhledem ke stavu v IdM nachází. Základní konfigurací synchronizace je nastavení typu akce, která má být v dané situaci provedena.

Synchronizační situace jsou pevně dané a jsou následující:

V této situaci je možné provést následující akce:

Aktualizovat entitu:Provede aktualizaci identity navázané na účet. Aktualizace se provádí na základě mapování navázaného na synchronizaci. Po uložení entity, dojde vždy k vyvolání standardního provisioningu.

Aktualizovat účet:Provede vyvolání standardního provisioningu. Synchronizace pouze vyvolá událost, samotný provisioning neprovádí.

Odstranit vazbu:Smaže vazbu v CzechIdM. Tzn. odstraní účet a vazby mezi identitou a účtem Neprovádí úpravu samotné identity, nevyvolává provisioning.

Odstranit vazbu a navázané role:Provede odstranění vazeb, jako v předchozím případě, ale navíc odstraní role identity, které jsou navázané na příslušné. Jinak řečeno, odstraní ty role, které daný účet identitě přiřadily.

Ignorovat:Tato akce neprovádí žádnou aktivní operaci.

Situace, kdy k danému účtu na systému neexistuje vazba (účet v CzechIdM), ale identita ano.

Protože vazba neexistuje, byla identita v tomto případě nalezena pomocí korelačního atribut. Korelačním atributem může být kterýkoli atribut z navázaného mapování synchronizace (korelační atribut je povinný). V této situaci je možné provést následující akce:

Vytvořit vazbu:Vytvoří vazbu v CzechIdM. Tedy vytvoří účet a vazbu mezi identitou a účtem. Neprovádí úpravu samotné identity, nevyvolává provisioning.

Vytvořit vazbu a aktualizovat účet:Vazba je vytvořena stejným způsobem jako v předchozím případě. Navíc je provedena aktualizace účtu na koncovém systému. To znamená, že. je vyvolána událost pro spuštění provisioningu.

Ignorovat:Tato akce neprovádí žádnou aktivní operaci.

Situace, kdy k danému účtu na systému neexistuje identita v CzechIdM. V této situaci je možné provést následující akce:

Vytvořit entitu:Vytvoří identitu a vazbu v IdM. Vytvoření se provede podle mapování nastaveného v synchronizaci. Vytvoření entity vyvolá provisioning (aktualizaci účtu).

Ignorovat:Tato akce neprovádí žádnou aktivní operaci.

Situace, kdy k danému účtu v IdM neexistuje účet na koncovém systému.

K této situaci může dojít v případě, že konektor podporuje operaci DELETE. Tzn. konektor je schopný informovat, jaké účty byly od doby poslední synchronizace smazány na koncovém systému. Typické využití této situace je ovšem v rekonciliaci, kde iterujeme přes všechny účty v CzechIdM a ověřujeme, zdali účet na koncovém systému existuje, pokud ne, je vyvolána nastavená akce. V této situaci je možné provést následující akce:

Vytvořit účet:Synchronizace pouze vyvolá událost pro navázanou entitu, která spustí provisioning, čímž dojde k vytvoření účtu na koncovém systému.

Smazat entitu: Smaže účet v CzechIdM, vazbu mezi účtem a identitou a identitu.

Odstranit vazbu: Smaže vazbu v CzechIdM. Tzn. odstraní účet a vazby mezi identitou a účtem. Neprovádí úpravu samotné identity, nevyvolává provisioning.

Odstranit vazbu a navázané role: Provede odstranění vazeb, jako v předchozím případě, ale navíc odstraní role identity, které jsou navázané na příslušný systém. Jinak řečeno, odstraní ty role, které daný účet identitě přiřadily.

Ignorovat: Tato akce neprovádí žádnou aktivní operaci.

Provisioning

Jde o propis objektů a jejich atributů do koncového systému. Základním typem provisioningu je provisioning Identit, kterým odpovídá objekt účtu v koncovém systému.

Konfigurace role pro provisioning

Aby mohl proběhnout provisioning, je třeba, aby uživatel měl v CzechIdM roli, která přiděluje daný systém a používá některé jeho mapování atributů. Pro nastavení role je přejdeme na záložku Role, kde vybereme požadovanou roli, která bude grantovat účet v systému například role „LDAP“. Klikneme na detail role pomocí znaku lupa a přejdeme na záložku „Napojené systémy“.

 \\
Obrázek 21: Přidání mapování systému na roli

Zde je seznam mapování provisioningu, který je nejčastěji prázdný, případně obsahuje jednu položku. Nebývá zvykem, aby role grantovala přístup do více systémů především kvůli přehlednosti. Pro přidání nového mapování provisioningu k roli klikneme na tlačítko „Přidat“.Máme možnost pracovat s následujícími položkami:

Dále je k dispozici sekce „Atributy mapované v rámci této role“. V této sekci lze přetížit vybrané mapování výše tak, aby do atributu objektu poslalo jinou hodnotu, než je ve vybraném mapování. Toho lze využít především tam, kde má některá role přidělovat specifické oprávnění a pochopitelně tedy toto oprávnění nelze nastavit v obecném mapování atributů na celém systému. Jde například o plnění atributu „MemberOf“ v MS Active directory, pokud daná role má uživatele zařazovat do AD skupiny.

Má-li uživatel alespoň jednu roli, která obsahuje tuto konfiguraci mapování atributů pro provisioning, pak je uživatel automaticky provisionován do daného systému kdykoli nad ním vznikne změna libovolného z mapovaných atributů.

Fronta pro provisioning

Propis dat v CzechIdM je realizován frontou požadavků na koncové systémy. Změní-li se například u Identity některý z jejích atributů a zároveň má identita účet pro některý napojený systém (např LDAP), pak je vyvolán zápis operace CREATE/UPDATE/DELETE do fronty provisioningu. Stejný princip platí pro všechny objekty, které podporují provisioning:

Na audit provisioningu se lze dostat následujícími cestami

V obou případech se dostaneme na stejný formulář, který obsahuje dvě záložky

fig:Fronta provisioningu funguje tak, že pokud existuje neprovedená operace pro nějaký objekt, třeba pro uživatele knovak,pak každá další operace pro tento objekt se řadí do fronty. Můžeme tak mít například pro knovak ve frontě následující řadu operací: CREATE, UPDATE, UPDATE, DELETE.

Manuální opakování operací provisioningu

Nejčastějším důvodem pro nevykonání provisioningu je nedostupnost systému, špatně nakonfigurované napojení na systém nebo přepnutí systému do režimu pouze pro čtení. V tom případě operace končí chybou a čeká ve frontě na vykonání. V CzechIdM můžeme tuto operaci provést manuálně tak, že označíme tuto operaci a z listu na výběr akce Operace s vybraným záznamem vybereme námi chtěný úkon. Na výběr máme ze dvou možností

Zrušit akciV obou případech jsme před samotným vykonáním dotázáni, zda chceme opakovat/zrušit celou dávku nebo pouze vybrané. V prvním případě budou ve stejném pořadí jako ve frontě opakovány všechny akce, které se vztahují k dané identitě. Například pro uživatele knovakto budou postupně všechny operace CREATE/UPDATE/UPDATE/DELETE.

Zvolíme-li možnost Opakovat pouze vybrané, pak se v pořadí, v jakém jsou umístěny ve frontě, vykonají/zruší pouze operace, které jsme dříve vybrali. Ostatní zůstanou nezpracovány ve frontě dále. V příkladu identity knovak bychom například vybrali CREATE/UPDATE, které by se v tomto pořadí vykonali/zrušili. UPDATE/DELETE by ve frontě zůstal. Opakování jednotlivých operací vyžaduje znalost napojení koncového systému. Pokud by administrátor například vybral operace, které nadávají smysl – například pouze DELETE, aniž by předtím použil CREATE, skončí toto volání chybou.

Automatické opakování operací provisioningu

V CzechIdM existuje dlouhotrvající úloha (LRT) s názvem RetryProvisioningTaskExecutor, která automaticky spouští frontu provisioningu v předem definovaných intervalech. Je-li tato úloha zapnutá, pak bude CzechIdM periodicky zkoušet provisioning pro operace, které má ve své frontě.

Chcete-li mít dlouhodobou odstávku napojeného systému, doporučujeme tuto úlohu z výkonnostních důvodů dočasně vypnout.

Detail operace provisioningu

Po kliknutí na znak lupy u každého záznamu ve frontě provisioningu získáme náhled na detail operace. Zejména zde vidíme následující položky:

Z těchto informací jsme často schopni přímo určit povahu chyby. V příkladu výše se zjevně jedná o špatně nastavené schéma pro provisioning, konkrétně je třeba upravit atribut __ENABLE__, aby přijímal Boolean nebo použít transformační pravidlo pro převod Boolean → String.

V detailu operace máme dále k dispozici dvě tabulky

Může se stát, že pravá tabulka je prázdná, a to zejména ve dvou případech

Audit historie workflow

Workflow reprezentují v CzechIdM nějaký proces – například Nová Identita, Nástup na mateřskou dovolenou. V podstatě se jedná o spustitelnou část aplikace, která tyto procesy realizuje. Z hlediska architektury se vlastně jedná o stavový automat, který v jednotlivých svých stavech vykoná nějakou předem definovanou akci. Například při vytvoření nové identity pošle email na nadřízeného. Nebo při odchodu zaměstnance vytvoří úkol na IT pro odebrání všech přístupů.

Všechna spuštění těchto workflow jsou evidována do auditního logu v menu Audit → Historie workflow. Název instance workflow je vždy tvořen názvem samotného forkflow a nějakou proměnnou, která nejčastěji definuje, pro který objekt je tato instance spuštěna. Například dle názvu Change permissions request for "Administrator" je zřejmé, že se jedná o workflow obsluhující žádost o změnu oprávnění a v této instanci bylo spuštěno pro uživatele „Administrátor“. Hodnoty proměnných v názvu workflow jsou zpravidla uvozeny uvozovkami.

Název workflow často obsahuje i názvy entit. Například pokud do filtru pro tento formulář vložíme do pole Názevhodnotu Administrator, pak získáme všechna workflow, která se týkala tohoto uživatele.

Naopak, pokud do pole pro Název vložíme „Change permissions request“, pak získáme všechny workflow pro žádost o změnu oprávnění pro všechny uživatele.

Napojení vzorového zdrojového systému

Základní nastavení

V této kapitole budeme připojovat vzorový systém jako zdroj identit. Využijeme základní Database Table Connector. Zdrojová tabulka, kterou budeme používat, má 4 sloupce: id, username, jmeno, prijmeni.

Nejprve na záložce Napojené systémy stiskneme tlačítko přidat. Zvolíme libovolný název systému, například Some base. Zaškrtneme volbu ReadOnly – naše databáze bude zdroj dat, nechceme do ní zapisovat. Ostatní atributy systému necháme ve výchozím stavu. Nakonec klikneme na Uložit a pokračovat.

Konfigurace konektoru

Přejdeme na záložku Konfigurace a zde vybereme konektor Database Table Connector (connId).Dále zadáme cestu k DB a přihlašovací údaje uživatele, kterým bude CzechIdM do DB přistupovat. Uživatel v databázi musí mít právo alespoň pro čtení z napojené tabulky. Konkrétně jsme v našem příkladu vyplnili:

V době psaní tohoto návodu lze driver pro PostgreSql stáhnout zde https://jdbc.postgresql.org/download.html

Kromě nastavení v konfiguraci systému v CzechIdM je potřeba soubor s ovladačem umístit do umístění pro knihovny aplikačního serveru. V našem případě běží CzechIdM v AS Tomcat, tedy driver umístíme do složky lib. Případně můžeme umístit driver do WEB-INF/lib přímo v umístění aplikace CzechIdM.

Ostatní atributy konektoru necháme nevyplněné nebo s výchozí předvyplněnou hodnotou.

Pokud jsme vše správně nastavili a CzechIdM má přístup do naší DB, můžeme konfiguraci ověřit kliknutím na zelené tlačítko Test konektoru na začátku stránky.

Schéma DB systému

Přejdeme na záložku Schéma systému (popsáno v kapitole 2.3.2) a klikneme na tlačítko Generovat schema. Konektor nám automaticky vrátí seznam dostupných atributů na napojovaném systému. Objekt vrácený z konektoru je ve výchozím stavu typu __ACCOUNT__, což nám pro napojení identit vyhovuje. Dále konektor vrátil podle očekávání 4 atributy dle našich sloupečků v DB. Ty zobrazíme kliknutím na obrázek lupy vedle typu objektu.

Navíc nám konektor ale vrátil atribut __NAME__, který je definován standardem ConnId. Námi použitá implementace Database Table Connector (connId) se této specifikace drží, avšak pro synchronizaci jej nepoužívá, proto pro naše načítání dat ze zdrojového systému jej nebudeme potřebovat.

Kliknutím na lupu vedle názvu atributu je možné zobrazit detaily konfigurace pro konkrétní atribut.

 \\
Obrázek 22: Detail atributu ve schématu systému

V našem případě mají všechny atributy stejnou konfiguraci až na atribut id a __NAME__, které jsou označeny jako povinné.

Mapování synchronizace pro DB

Máme-li připravené schéma systému, pak přikročíme k mapování synchronizace. To nám umožní určit, jaké atributy z dostupného schématu nasynchronizujeme do IdM a také do kterých atributů Identity se budou atributy z účtu plnit.

Na záložce mapování atributů stiskneme tlačítko Přidat.Vyplníme

Po vytvoření mapování klikneme na detail tohoto mapování a nastavíme konkrétní vazby atributů účtu na atribut identity. Nastavíme mapování pro všechny naše atributy id, name, surname, username.

fig:Například atribut id nastavíme dle následujícího obrázku. Ostatní atributy nastavím stejně až na položky

Jak je vidět, ne všechny atributy musíme mapovat na atribut v CzechIdM. Ty, které nenamapujeme, nebudou vyplněny k entitě v CzechIdM. V našem případě se k entitě nepřenese id, které nechceme dále využívat, ani jej neplánujeme posílat do spravovaných systémů.

V našem příkladu jsme namapovali atributy účtu na systému na základní atributy Identity. Každá entita v CzechIdM má základní sadu atributů, které však lze rozšířit. Chceme-li v synchronizaci namapovat atributy na rozšířené atributy entit v CzechIdM musíme mít nejprve přichystán formulář EAV atributů pro danou entitu, viz kapitola 2.10.

Nastavení synchronizace

V předchozí kapitole jsme si připravili mapování atributů pro synchronizaci. Nyní nastavíme samotný proces synchronizace, který toto mapování bude používat.

Přejdeme na záložku Synchronizace a klikneme na tlačítko přidat. V synchronizaci vyplníme název a povolíme ji dle obrázku. Rekoncilace můžeme zaškrtnout také, budeme načítat všechny účty bez omezení. Do sady mapovacích atributů vybereme mapování users, které jsme si vytvořili v minulé kapitole.

Dále přejdeme ve formuláři až k nastavení operací pro jednotlivé stavy účtu a entity a nastavíme následujícím způsobem:

Položky Workflow necháme nevyplněny, ty slouží pro pokročilé skriptování u jednotlivých akcí.

Na podzáložce Filtr nenastavujeme nic, nechceme omezovat synchronizaci pouze na některé účty. A záložka Logy je pouze informativní a obsahuje auditní log synchronizace.

Spuštění synchronizace a log

Pokud jsme úspěšně prošli nastavením v předchozích kapitolách, můžeme nyní přistoupit ke spuštění samotné Synchronizace. Přejdeme na záložku Napojené systémy, vybereme náš nakonfigurovaný systém a přejdeme na záložku Synchronizace. Synchronizaci spustíme zeleným tlačítkem se znakem trojúhelníku na konci řádku s konfigurací synchronizace.

Běžící synchronizace mají vyplněn sloupeček Běží. Pokud přejdeme na detail běžící synchronizace (kliknutím na znak lupa) a poté přejdeme na záložku Logy, vidíme přehled všech synchronizací, včetně aktuálně běžících.

Virtual Systems

What is virtual system

A virtual system is not directly connected for online management. The virtual system is basically only a registration mode, where for each system change is generated the implementation request (notification) that is assigned to the particular administrator. This administrator must provide that the change is made to the target system. In other words, IdM "knows" what the user should have on the system for accounts and permissions, but on the real system this is executed by the implementer (administrator). The reason may be the need to manage a large number of systems without the need for demanding integration.

How to create virtual system

It shows a dialog for creation a new virtual system.

You can fill:

Beware: Users/roles have to have permission 'Requests on virtual systems (VsRequest)' to receive these requests.

In details of a new virtual system is by default configured system schema, mapping and attributes

Create new role

We have created new virtual system. Now we will assign system to some users. For this we create new role and create mapping for our new virtual system.

Create mapping on virtual system

Create new user

We will create new user and assign him our role, so he will be provisioned to our new virtual system.

Requests

Implementers received new task to create new account 'john.doe' on virtual system 'NewVirtualSystem'. You can check request In left main menu select 'Virtual systems / Request'. There are two tabs 'Unresolved requests' and 'Archive'. In 'Unresolved requests' there is list of all tasks, which yet will be resolved.

If you did previous tutorial, you have here this request. You can go to detail of request with UID 'john.doe' and system 'NewVirtualSystem' (click on button with "magnifying glass"). And you can now see detail of request for creating new account.

There are three specific information:

If we do not resolve create request and edit our user 'john.doe', e.g. change surname to Doe. In 'Unresolved requests' There is new update request. Click detail of update request.

When we finally resolve our two requests, there are moved to tab 'Archive'.

Operation with request

Realize request

Cancel request

Permissions

Notifications

After request for updating virtual system is created, notification is sent to all implementers.

As default was implemented email notification 'vs:vsRequestCreated' for new virtual system request. This notification is by default automatically connected to this topic. Template for this notification can be modified in left main menu 'Notifications / Templates'.

Email template provides similar informations as request detail (described above). For example 'Target table' is constructed from same data as table on request detail. Below is examples of notification emails send during process create and modify account 'john.doe' and notification, which show change of multivalue attribute.

Email notification for create new account 'john.doe':

Email notification for modify account 'john.doe':

Email notification for modify multivalue attribute 'ldapGroups' for account 'john.doe'.

To the attribute was added new values 'E,F' and removed values 'C,B':

Deleting virtual system

ACC and VS module integrity missing. When system in ACC module is connected to VS module and then will be system from ACC module deleted, then none action will be executed on VS module. None integrity check or delete of VS requests!