All posts by Jan

Nové možnosti delegování úkolů v CzechIdM

Možnost delegovat své schvalovací úkoly na jinou osobu máme v CzechIdM již delší dobu. V nedávné době se nám od našich zákazníků sešlo několik požadavků, jak tyto delegace dále zlepšit a rozšířit. Jedním z požadavků například bylo, aby administrátor s danými právy mohl nastavovat delegace za jiné uživatele. Dále jsem se rozhodli přepracovat GUI delegací tak, aby bylo pro uživatele přívětivější. Pojďme se tedy na tyto změny podívat.

czechidm

 

Práva pro administrátory k delegování

Dříve právo na delegování svých úkolů měli pouze uživatelé samotní, což se v některých případech ukázalo jako nepraktické. V lepším případě uživatel jen odjel na dovolenou a úkoly zapomněl delegovat na svého kolegu. Pokud by chtěl administrátor delegování nastavit místo onoho uživatele měl jedinou možnost. Resetovat heslo do CzechIdM, změnit nastavení a pak uživateli vysvětlit, že si má nastavit nové heslo.
Nyní se administrátor přihlásí do admin rozhraní a u všech uživatelů, které má ve své kontrolované organizaci má možnost kliknout na Delegovat úkoly ve sloupci Akce. Odkaz administrátora přenese na delegaci úkolů daného uživatele. Aby mohl administrátor takto přejít na delegaci úkolů, musí mít přidělená oprávnění, což je možné dvěma způsoby:

  • Jedná se o administrátora, který má přidělenou superAdmin roli, tudíž může vše
  • Jedná se o normálního administrátora, tudíž musí mít přidělenou admin roli s oprávněním:
    • USER_TASK: DELEGATE
    • USER: READ – pro čtení seznamu uživatelů (není nutné, pokud má oprávnění přidělené pomocí jiné role
    • ORGANISATION: READ – pro čtení organizační struktury (není nutné, pokud má oprávnění přidělené pomocí jiné role)

users_delegace_ukolu_u

Přívětivější GUI delegací

Díky častému nasazení a použití delegací v některých projektech jsme zjistili, že původně navržené GUI není tak intuitivní, jak jsme byli přesvědčeni. Proto jsme přistoupili k jeho změně a nyní formulář uživatele opticky provede celým nastavením delegací. Navíc uživatel okamžitě v přehledu na stejné stránce vidí, jaké nastavení delegací má nastavené.

delegace_u

Nejprve uživatel vybere čas, kdy má být delegování aktivní, následně na koho se mají úkoly delegovat a následně novou delegaci uloží.
Po uložení delegace musí uživatel, na kterého mají být úkoly delegovány, požadavek schválit. Stav uživatel vidí v přehledu delegací ve spodní části stránky.

Závěr

V článku jsme si ukázali novou funkci pro delegování úkolů, která dává administrátorovi další práva a nové GUI, které je nyní daleko přívětivější. Pokud byste měli zájem o další informace o delegování nebo měli jakékoliv otázky, můžete mě kontaktovat na info@bcvsolutions.eu.

 

CzechIdM umí synchronizovat i bez programování

Za několik málo dní nastane pro CzechIdM velká událost, kterou ještě nebudu prozrazovat. Nicméně se snažíme CzechIdM na tento krok do neznáma připravit tak, aby jej zvládl a obstál se ctí. S tímto velkým krokem souvisí fakt, že se snažíme CzechIdM rozšířit tak, aby jej administrátor pouze nainstaloval a vše mohl nakonfigurovat v grafickém rozhraní, případně v konfiguračních souborech. Do nedávna musel administrátor mnoho věcí programovat v Javě resp. BeanShellu, mezi které patřila i synchronizace a rekonciliace napojených systémů. Udělali jsme zásadní rozhodnutí a nyní si oboje může administrátor nakonfigurovat, nebo naprogramovat, pokud preferuje tuto variantu. Pozn.: Nadále pro jednoduchost budu mluvit jen o synchronizaci, nicméně je tím myšlena i rekonciliace. V opačném případě bude uvedeno explicitně.

Workflow pro každý účet

Jak už jsem výše uvedl, administrátor musel pro každý napojený systém naprogramovat synchronizačním workflow, které v praxi bylo pro mnohé systémy velmi podobné. Výhodou tohoto řešení byla a stále ještě je, veliká variabilita, kdy s účtem a spárovanou identitou můžete dělat úplně cokoliv vás napadne. Jsou systémy, kde takovéto řešení je jediné možné, ale těch je velice málo. Naopak nevýhodou je fakt, že se pro každý synchronizovaný účet a identitu spouští workflow stále dokola, což má neblahý vliv na výkon, kdy vytváření jeho kontextu je řádově pomalejší než implementace v kódu.

Standardní implementace

Jestliže je workflow oproti klasickému kódu o tolik pomalejší, proč jej nevyužít pro synchronizaci? Zvlášť, když by bylo možné takto nakonfigurovat synchronizaci daleko rychleji, pohodlněji? Proto jsme zpracovali rozsáhlou analýzu problému a ujasnili si tak, co synchronizace v rámci workflow ve většině případů dělá. Po velké diskuzi nad tímto tématem jsme se pustili do implementace a nyní vám můžu hrdě a s radostí oznámit, že vše je dokončeno. Implementaci si v tuto chvíli nechám pro sebe a rovnou se vrhnu na jednoduchý modelový příklad, na kterém si vše ukážeme. Po tomto příkladu bude následovat rychlý přehled dalších funkcí, kterým se bude věnovat některý z dalších článků.

Používané termíny

Nejprve si musíme ujasnit některé termíny, které budu dále v příkladu používat:

  • účet – jeden účet na koncovém systému
  • identita – osoba v CzechIdM (může mít více účtů)
  • synchronizace – proces, kdy se zpracovávají jen změněné účty na jednom systému
  • rekonciliace – proces, kdy se zpracovávají všechny účty na jednom systému
  • korelace – podmínka, na jejímž základě se pokouší synchronizace přiřadit účet konkrétní identitě
  • stav synchronizace – stav spárování účtu s identitou; může být:
    • ASSIGNED – účet je již přiřazen konkrétní identitě
    • MATCHED – účet a identita si odpovídají na základě korelace
    • MISSING_IDENTITY – existuje účet na koncovém systému, ale v CzechIdM neexistuje odpovídající identita
    • MISSING_ACCOUNT – existuje identita, která by měla na základě role mít účet na koncovém systému, ale nemá jej. Tento stav může nastat pouze u rekonciliace.

Modelový příklad

Neuvedu zde suchý výčet všech možností synchronizace, ale vše ukážu na jednoduchém případě. Výčet a popis všech možností bude uveden v dalším článku, na který se můžete již teď těšit. Nyní tedy k modelovému příkladu – předpokládejme dva koncové systémy na kterých existují účty a CzechIdM, které jsme si čerstvě nainstalovali a nyní chceme napojit oba systémy. První koncový systém je Personalistika, ve které primárně vznikají účty při příchodu nového zaměstnance. Naopak po jeho odchodu se účet smaže a pokud měl účet na druhém systému s názvem Doména, tak se také smaže.

Vidíme, že se nám tu již tvoří seznam požadavků na synchronizaci, tak si jej zde uvedeme trochu podrobněji:

  1. Pokud vznikne nový účet na systému Personalistika, vznikne odpovídající identita.
  2. Synchronizace systému Personalistika bude probíhat každých 10 minut.
  3. Pokud nebude existovat účet na systému Personalistika, smaže se identita a přiřazený účet na systému Doména.
  4. Ze systému Personalistika se budou načítat veškeré atributy kromě emailu.
  5. Pro nově vytvořenou identitu se vytvoří účet na systému Doména.
  6. Domovská organizace z personálního systému bude top:zaměstnanci, ale pouze při vytvoření identity.
  7. Atribut identity email se bude vždy aktualizovat ze systému Doména a následně se bude zapisovat do systému Personalistika.
  8. Pokud existuje účet na systému Doména a neexistuje odpovídající účet v systému Personalistika, tento účet je určen k zablokování a budeme o něm informovat administrátory.
  9. Rekonciliace systému Personalistika bude probíhat jednou denně.
  10. Synchronizace systému Doména není nutná a proto bude probíhat jen kontrolní rekonciliace jednou denně, která bude aktualizovat email u identity.

Nastavení systémů

Předpokládáme, že oba systémy jsou napojeny pomocí DatabaseTable konektoru a vše potřebné pro připojení je již hotové.

Nastavení atributů systému Personalistika

Na následujícím obrázku je patrné jaké atributy jsou na systému Personalistika a jak jsou mapovány do CzechIdM. Je zde několik důležitých atributů kromě jména a příjmení. Jedná se hlavně o atributy “DISABLED”, který slouží k indikaci zablokovaného účtu a “PASSWORD” kde je uloženo heslo k účtu. Dalo by se říct, že toto je již notoricky známé nastavování atributů systému a proto jej zde nebudu dále rozvádět.

Atributy_schematu_personalistika

Nastavení synchronizace systému Personalistika

Zde můžeme již vidět první nový formulář nastavení, který slouží k nastavení akcí při synchronizaci, konkrétně systému Personalistika. Jak můžeme vidět, pro každý stav synchronizace můžeme nastavit výkonnou akci a informativní akci. Výkonná akce upravuje účet nebo identitu a informativní akce informuje o stavu nebo výsledku. O dalších možnostech nastavení se budete moci dočíst v některém z dalších článků. Nyní se vrátíme k seznamu požadavků a vysvětlíme si, čím v tomto případě zajístíme jejich splnění.

Nejprve tedy první požadavek: Pokud vznikne nový účet na systému Personalistika vznikne odpovídající identita. Nový účet je značen stavem MISSING_IDENTITY, proto pro tento stav zvolíme možnost CREATE_IDENTITY, která nám identitu vytvoří a na základě mapování doplní.

Druhý požadavek zní: Synchronizace systému Personalistika bude probíhat každých 10 minut. Toto nastavíme jednoduše pomocí časovače, jak je uvedeno na obrázku.

Ostatní stavy synchronizace jsou nastavené tak, jak nepřímo plyne ze čtvrtého požadavku: Ze systému Personalistika se budou načítat veškeré atributy kromě emailu. Aby se toto skutečně mohlo dít i v čase, kdy se data v systému Personalistika mění, je nutné mít nastavené u stavu ASSIGNED volbu UPDATE_IDENTITY, která aktualizuje identitu. Pro stav MATCHED pak nastavíme LINK_AND_UPDATE, který dělá to samé jako UPDATE_IDENTITY, ale navíc spáruje účet s identitou.

Jako perlička je uvedena informativní akce pro stav MISSING_IDENTITY a to REPORT_ONLY_IF_ERROR, která odešle email pokud dojde během vytváření identity k chybě. Administrátor tak okamžitě zjistí, že došlo k chybě a může sjednat nápravu.

Nastaveni_synchronizace_systému_personalistika

Nastavení rekonciliace systému Personalistika

Synchronizaci již máme nastavenou, teď tedy k rekonciliaci, díky které je možné splnit čtvrtý požadavek: Pokud nebude existovat účet na systému Personalistika, smaže se identita a přiřazený účet na systému Doména. Chybějící účet je signalizován stavem MISSING_ACCOUNT, který může nastat pouze u rekonciliace, proto zde nastavíme možnost DELETE_IDENTITY. Ta nám zaručí smazání identity, který chybí účet na systému Personalistika a zároveň smazání všech ostatních účtů na koncových systémech.

Opět je zde přidána jedna perlička – nastavená hromadná akce REPORT_ONLY_IF_ERROR. Hromadná akce se spouští vždy po dokončení synchronizace nebo rekonciliace a volba REPORT_ONLY_IF_ERROR zaručí, že jakmile u jakéhokoliv účtu dojde k chybě, bude odeslán e-mail na zadanou adresu. Narozdíl od informativní akce, kde se odešle e-mail pro každou identitu, kde nastala chyba, zde se odešle pouze jeden e-mail s celkovým přehledem.

Nastaveni_rekonciliace_systému_personalistika

Nastavení mapování atributů pro systém Personalistika

Nyní se podíváme na mapování atributů pro systém Personalistika. Možná vás mate, že už jsme jednou atributy pro tento systém nastavovali, ale je to tak správně. Toto mapování totiž určuje, jak se budou vyplňovat atributy u identity, jakmile se má identita vytvářet nebo aktualizovat. Oproti tomu nastavení atributů u systému pouze určuje, jak se atributy z koncového systému budou předávat do CzechIdM a naopak.

V tomto mapování určíme jednoduše čím a jak se budou vyplňovat atributy identity při jejím vytváření ze systému Personalistika. Zde splníme požadavky:

  • Ze systému Personalistika se budou načítat veškeré atributy kromě emailu
  • Pro nově vytvořenou identitu se vytvoří účet na systému Doména
  • Domovská organizace z personálního systému bude top:zaměstnanci, ale pouze při vytvoření identity.

První bod zajístíme tím, že zde atribut “email” neuvedeme a nebude se tedy do identity doplňovat. Ostatní atributy se do identy dostanou díky nastavení zdroje RESOURCE_ATTRIBUTE, který značí, že se atribut načte z koncového systému. Pouze musíme vyplnit jakým atributem na koncovém systému se má hodnota vyplňovat. Důležitým atributem je atribut “name”, který je identifikátorem identity.

Druhý bod je o trochu těžší, ale po vysvětlení se bude vidět jeho elegance – účet na koncovém systému je vždy definován rolí, kterou má identita přiřazenou. Chceme-li zakládat účet při založení identity, přiřadíme jí roli pro daný systém a tím pádem se účet na koncovém systému (zde Doména) vytvoří automaticky. Je nutné zároveň identitě přiřadit roli pro systém Personalistika, kde je synchronizace spouštěna, aby se účet mohl s identitou spárovat. Pro splnění druhého bodu tedy musíme atribut “roles” vyplňovat ze zdroje CONSTANT, neboli konstantou, která je uvdena vedle. Zde je uvedený seznam rolí oddělených znakem “|” a jako datový typ je zde “List<String>”.

Třetí bod splníme tím, že atribut “homeOrganisation” u identity budeme vyplňovat opět konstantou jako v předchozím případě, jen s tím rozdílem, že hodnota bude “top:zaměstnanci”. Druhá část tohoto bodu je zajištěna tím, že se zvolí strategie zápisu CREATE, což značí, že se atribut bude v tomto stavu aplikovat pouze při vytvoření identiy a při aktualizaci se bude ignorovat.

Mapovani_atributu_synchronizace_personalistika

Nastavení atributů systému Doména

Na následujícím obrázku je patrné jaké atributy jsou na systému Doména a jak jsou mapovány do CzechIdM. Je zde několik důležitých atributů kromě jména a příjmení. Jedná se hlavně o atributy “DISABLED”, který slouží k indikaci zablokovaného účtu a “PASSWORD” kde je uloženo heslo k účtu. Dalo by se říct, že toto je již notoricky známé nastavování atributů systému a proto jej zde nebudu dále rozvádět.

Atributy_schematu_domena

Nastavení rekonciliace systému Doména

Abychom splnili požadavky pro napojený systém Doména musíme rekonciliaci nastavit následujícím způsobem. Zrekapitulujeme si požadavky:

  • Atribut identity email se bude vždy aktualizovat ze systému Doména a následně se bude zapisovat do systému Personalistika
  • Pokud existuje účet na systému Doména a neexistuje odpovídající účet v systému Personalistika, tento účet je určen k zablokování a budeme o něm informovat administrátory.

První bod znamená, že se musí identita vždy aktualizovat a proto pro stav ASSIGNED je nastavena akce UPDATE_IDENTITY. Pro stav MATCHED je nastaveno opět LINK_AND_UPDATE. Zároveň pokud chybí účet na systému Doména ale identita má roli přiřazenou, tak dojde ke stvu MISSING_ACCOUNT a protože chceme účet vytvořit, nastavíme CREATE_ACCOUNT.

Druhý bod je opět stejně jednoduchý – stav o kterém se zde bavíme je MISSING_IDENTITY a proto zde nastavíme možnost DISABLE_ACCOUNT, která účet zablokuje na základě politiky blokování účtu na systému. Jelikož by tento stav nastávat neměl, chceme informovat administrátory a proto nastavíme jako informativní akci REPORT a vyplníme e-mailovou adresu.

Nastaveni_rekonciliace_systému_domena

Nastavení mapování atributů pro systém Personalistika

Opět je pro rekonciliaci nastavit mapování atributů ze systému do identity. Je zde řádově méně položek, jelikož Doména je autoritativní zdroj jen atributu email, který se tím pádem načte při každé rekonciliaci do identity. Dalším uvedeným atributem jsou přiřazené role. Jelikož může nastat situace MATCHED, kdy identita odpovídá účtu na základě korelace a zároveň identita nemusí mít přidelenou roli, tak jí tímto způsobem identitě přiřadíme. Stačí, když nastavíme typ zápisu APPEND, což zajistí, že uživateli roli přidá, pouze pokud ji nemá a zároveň ponechá všechny ostatní přidělené role.

Mapovani_atributu_reconciliace_domena

Drobná poznámka před koncem

Takto uvedený postup, kdybyste vše nastavili a spustili, by fungoval zcela správně, pouze pokud by na sytému Doména nexistoval jedinný účet. Pokud by existoval účet, který by měla identita měla vytvářet, dojde k nekonzistenci dat. Pokud byste chtěli takto postupovat, stačí při první synchronizaci systému Personalistika do atributu “roles” nepřidávat roli pro systém Doména. Následně spustit rekonciliaci systému Doména, kde by u všech identit nastal stav MATCHED a role by se identitě přidala. Poslední krok by byl přidáním role do atributu “roles” u synchronizace systému Personalistika.

Závěr

Ukázali jsme si na názorném příkladu, jak by probíhalo nastavení jednoduché synchronizace a rekonciliace u dvou systémů. Představte si, jak byste takové věci složitě programovali – není to úleva, že nyní již nemusíte? :-) O dalších možnostech nastavení si budete moct přečíst v dalším článku.

V případě jakýchkoliv připomínek či dotazů mě kontaktujte na info@bcvsolutions.eu.

The new monitoring of CzechIdM system

From the moment that you could read the article about tools for monitoring our Identity Management CzechIdM, had passed quite a few months and now we made a progress. In the new version CzechIdM, which is being tested and will soon be presented to the public, there is active monitoring and sophisticated environment offers many opportunities for administrators and most simple configuration.  Let’s look what we can in the new version CzechIdM monitored and how monitoring customize to your liking.

 

Diagram of solutionsdiagram_en

The Admin interface

In the administration interface CzechIdM there is a new tab in the main menu called “Status Page”.

synchronization_attribute_mapping3

 

If you click on it, Czech IdM starts a set of tests and displays a table with the results.

synchronization_attribute_mapping4

Each line corresponds to one test:

  • The column “Type” describes the type of test, ie the information if the connection has been tested on any of the connected systems, regular starts of  synchronization, functionality of a particular user or your own code.
  • In the “Target” is the name of the test subject, in case of test connection with the connected system, is there name of the system.
  • Result” contains key information on how things turn out, whether successfully or not.
  • Time elapsed” means the time required by the test. In milliseconds.
  • Message” may contain additional information. When you find that any of the tests fared badly, here you can begin to investigate why.

Administrator therefore just one click and he knows what is OK and what isn’t. CzechIdM runs required set of controls and displays the results in a table.

Configuration

Scope of of tests and their parameters can be set according to your wishes in the configuration file BCV_IdM-ear.ear/BCV_IdM-ejb.jar/META-INF/idm_configuration.properties. Tests have five parameters, their names all begin with the prefix “status_”:

  • status_resources – List of connected systems, which is to be monitored connection with CzechIdM. Delimiter in the list is a semicolon, for each system you can define a time limit for the test, per colon. Use the special string “__ALL__” instead of the name of the system can determine that are to be tested all of the associated systems.
  • status_users – list of users to which the operation is “checkout-checkin”, the updating of information in CzechIdM from the source systems and the inclusion of this information in connected systems. Again, you can specify multiple users by separating them with a semicolon, again, you can set a time limit for each user.
  • status_synchronizations – list of connected systems, which should be checked for regularly starting synchronization. With each system name there is the maximum interval between synchronization runs separated by coma, different systems are separated by a semicolon.
  • status_recons – similar to status_synchronizations, instead of synchronizing is checked regularly starting reconciliations
  • status_custom_rules – tests tailored for advanced users. Can you provide a list of rules to be launched, along with every timeout and expected (error less) result.

All times are given in milliseconds.

Example configuration:

status_resources=Active Directory:10000;Docházky:5000;MySQL:5000
status_users=novakj:5000;pokornyp:6000
status_synchronizations=MySQL:3600000;Active Directory:900000
status_recons=MySQL:36000000
status_custom_rules=myRule1:10000:OK;myRule2:10000:SUCCESS

The above configuration ensures that every time you start the tests will be checked connection systems “Active Directory”, “Docházky” and “MySQL”, the success will be considered if the test for “Active Directory” ends correctly within 10 seconds, other two systems ends correctly within 5 seconds.

Plugin for Nagios

In the screenshot at the introduction you saw a table in the admin interface. For machine processing is more suited its text CSV format. It can be downloaded from the running CzechIdM from address /idm/admin/status/showcsv.seam. For regular monitoring you can use a script checkIdMStatus.sh that comes along with the new version. Before you run it, open it for editing and set the variables at the beginning of the script according to their own use, especially login name and password. If you set run of script in cron or if you use it as part of the monitoring system Nagios, it arrives you reporting on failed test by e-mail (please check that you correctly functioning command “mail” from the shell and you do not have very strict firewall for sending mails). Please make sure to limit the rights for the script, it contains the login name and password.

Conclusion

CzechIdM provides for administrators a new way of active monitoring. A specific set of tests may vary on individual deployments, the administrator it can easily customize the configuration file idm_configuration.properties without having to restart the application server running CzechIdM. Along with CzechIdM is also supplied control script that can serve as a plugin for Nagios. If you need help or would like some upgrades to the next version, email me at jan.effenberger@bcvsolutions.eu.

Delegation of the approval request in CzechIdM

Delegation of the approval request extends options of requests in CzechIdM. This function gives users opportunity dynamically to choose own deputy, who have been entrusted approving incoming requests.

The basic functionality

Delegation, in their basic functionality, allows users move own rights and responsibility related with requests in CzechIdM to other user or a group of users. The user only needs to choose in CzechIdM web interface some other user(s), to whom he would want to delegate own requests and, when the deputy accepts this responsibility delegation, this delegation becomes active without any complicated administration.

Now all of approval requests will stop comes to original approval and it is sent to every active deputy. Every one of this deputies has full rights to approve or reject this request. When someone finishes the request, it is regarded as closed and it is deleted from list of waiting requests by other deputies.

 Time limitation

In choosing deputy is possible in delegation form choose start-date and end-date of delegation validity. This choice enables various options of delegation, then in practice delegation is not active before start neither after end of validity. CzechIdM treats with inactive delegations like they don’t exist – i.e. when user has a lot of delegations but all of them are inactive, CzechIdM sends every request to him.

Specifying start-date or end-date is not mandatory and nothing prevents to user leave one or both fields in form empty. Without specifying end-date is delegation indefinitely (until user cancel it). Without specifying start-date delegation is valid at the moment of confirmation by deputy.

Using the delegation

Users with relevant rights have access to tab “Delegate tasks” in CzechIdM in Tasks section. On this site there is shown overview of all delegations with the time intervals during which are tasks delegated to the deputy (or deputies). By pressing the Edit button we move to the displayed form below, which is for create new delegation.

1
Form for delegation editation in CzechIdM

By pressing button „Select user“ displays dialog box, which allows searching in list of other users and their filtration by user-name, first name or last name.

2
The dialog box for deputy selection when creating a new delegation

After selecting a user is added to the list of selected users. In the right part of form is possible to specify start-date and end-date of delegation validity.

3
Selecting start-date and end-date when creating a new delegation

After selecting users and time range is need to create the delegations. To do this is there button Select, after its pressing is created one line in list of selected users for each user, with time details.

4
The result of adding a new delegation to the table

In this table is possible to delete any existing delegation (using option „Delete“ at the end of line). To close the edit form are there two buttons on the bottom of the form. By selecting Close the form is only closed and all changes are discarded. The Save option saves all changes to the system and after that closes form. Deleting the existing delegations takes effect immediately but creating a new delegation take effect until after that the deputy approved the delegation.

Delegation in the cascade…

The system does not restrict users to delegation their requests to someone who delegates his request also, even on several levels. The resulting cascade behaves so that any request addressed to one of the users in the resulting delegation concatenation, gradually passes through all participants in the chain and is sent only to the user at the end.

… and in the circle

In the event that users consciously (or unconsciously) close the chain of delegation – ie in chain of delegations would occur one user on two different places – a situation can be call delegation in the circle. System in this situation can not adequately determine to whom requests should be delivered, therefore contains a fuse that will ensure that in the case of delegation in circle, all requests sent to participants in the circle, are sent to the original recipients.

Conclusion

Described delegation function is already standard component of our Identity Manager CzechIdM. Currently, we are planning further extension the functionality for better overview and control and from the perspective of the delegate and few administration functionality for easier delegation management. If you are interested or questions please contact me at jan.effenberger@bcvsolutions.eu.

 

Standardní synchronizace v CzechIdM – základní souhrn

Za několik málo dní nastane pro CzechIdM velká událost, kterou ještě nebudu prozrazovat. Připravujeme CzechIdM na tento krok do neznáma tak, aby jej zvládl a obstál se ctí. Velkým úkolem je i zjednodušení instalace a konfigurace. Cílem je, aby administrátor CzechIdM pouze nainstaloval, aby vše mohl nakonfigurovat v grafickém rozhraní, případně v konfiguračních souborech.

Do nedávna musel administrátor mnoho věcí programovat v Javě resp. BeanShellu, mezi které patřila i synchronizace a rekonciliace napojených systémů. Udělali jsme zásadní rozhodnutí – nyní si administrátor může synchronizaci i rekonciliaci nastavit jednoduše v admin rozhraní CzechIdM.

czechidm-synchronisation

Workflow pro každý účet

Administrátor dříve musel pro každý napojený systém naprogramovat synchronizačním workflow, které v praxi bylo pro mnohé systémy podobné. Výhodou tohoto řešení je veliká variabilita, s účtem a spárovanou identitou můžete dělat úplně cokoliv vás napadne. Jsou systémy, kde takovéto řešení je jediné možné, ale těch je velice málo.

Naopak nevýhodou synchronizačního workflow je fakt, že se pro každý synchronizovaný účet a identitu spouští workflow stále dokola, což má neblahý vliv na výkon, kdy vytváření jeho kontextu je řádově pomalejší než implementace v kódu

Implementace synchronizace

Jestliže je workflow oproti klasickému kódu o tolik pomalejší, proč nevyužít právě nativní kód pro synchronizaci? Zvlášť, když by bylo možné takto nakonfigurovat synchronizaci daleko rychleji a pohodlněji?

Proto jsme zpracovali rozsáhlou analýzu problému a ujasnili si tak, co synchronizace v rámci workflow ve většině případů dělá. Po velké diskuzi nad tímto tématem jsme se pustili do implementace.

Nyní vám můžu hrdě a s radostí oznámit, že CzechIdM nabízí standardní synchronizaci přímo v admin GUI. Pro tuto chvíli si nechám pro sebe veškeré možnosti nastevení a jak je vše realizováno. To si budete moci dočíst v některém z dalších článků.

Přínosy standardní sycnhronizace

Jeden z velkých přínosů už byl uveden již výše – nenutíme administrátora programovat, nýbrž se snažíme aby naopak CzechIdM sloužilo právě administrátorovi. Co je tedy konkrétním přínosem?

  • Rychlé a jednoduché nastavení synchronizace
  • Přehledné reportování výsledků
  • Odolnost proti chybám při synchronizaci
  • Rozsáhlé možnosti plnění atributů u identity
  • Přizpůsobivost pro velké množství scénářů synchronizace

Přehled jak vše probíhalo

Prvotní návrh, jak vše implementovat spočíval ve dvou dokumentech. V prvním byla jen představa, co by se nám líbilo. Druhý dokument pak již obsahoval konkrétní návrh, jak vše implementovat. U druhého dokumentu jsme ve více lidech trávili relativně mnoho času, ale výsledkem byl detailní soupis, podle kterého bylo možné vše okamžitě realizovat. Po této analýze nastala pro programátory oblíbená doba implementační. Souběžně s každou fází probíhala i dokumentační část a nemalá část času padla i na projektové řízení, které opět probíhalo souběžně.

Kdybych to měl shrnout, tak z celkového stráveného času nejvíce zabrala implementace – cca 50%. Vše je přehledně vidět v následující tabulce.

Implementace: 53%  (5MD GUI včetně workflow + 12MD samotná implementace v kódu)
Analýza: 16% (5MD – dokumenty s prvotním návrhem a následnou analýzou)
Testování: 15% (5MD – včetně přípravy všech testovacích dat)
Dokumentace: 6% (2MD – od dokumentace kódu až po tutorial jednoduchého nastavení)
Projektové řízení: 6% (2MD – veškeré práce spojené s řízením projektu a rozhodováním)
Ostatní: 4% (2MD – vše co se nevešlo jinam, ale přesto souvisí s úkolem)

Závěr

Na této nové funkčnosti pracovali v průběhu času všichni vývojáři v našem týmu a tímto jim děkuji za skvěle odvedenou práci. V případě jakýchkoliv připomínek či dotazů ohledně synchronizace mě kontaktujte na jan.effenberger@bcvsolutions.eu.

Novinky v CzechIdM 09/2013

Jak jistě víte, vývoj softwarového produktu je nikdy nekončící záležitost. Neustále je potřeba přidávat nové funkce a zdokonalovat ho. CzechIdM není výjimkou a vývoj neustále pokračuje. Proto bych zde rád uvedl tři vylepšení, které můžete v následující verzi potkat. Jen si dovolím malé ubezpečení – nejsou to jediné změny, které v další verzi naleznete.

czechidm-tisk

Continue reading

JavaDoc tipy & triky

Každý se s tím zajisté již mnohokrát setkal. Pročítat si cizí kód a dokonce i vlastní bývá velice obtížné. Nikdy nevíme co se programátorům honilo hlavou, když psali zrovna takovou podmínku. Co je vedlo k tomu, že je cyklus omezený právě takhle? Spousty podobných otázek si kladl každý z nás. Já sám jsem se v takové situaci ocitl přesně ve chvíli, kdy jsem se stal novým členem týmu BCVsolutions s.r.o. Již v prvních dnech jsem si musel pročítat stovky řádků kódu a ještě  rozsáhlejší dokumentaci.

sourceCode

Continue reading

Prezentace o novinkách v CzechIdM

V rámci interních školení u nás proběhla prezentace vyvíjených novinek v CzechIdM. Vývoj každé novinky znamená předvést motivaci, všechna možná řešení a podrobit vybrané řešení velké diskuzi. Je to jedním z nástrojů, kterým můžeme zajistit kvalitu produktu, která je pro nás prioritou. Jaká témata jsme v prezentaci probírali se dozvíte z agendy níže.

Continue reading