Archiv pro rubriku: BCV

CzechIdM je nyní dostupný pod svobodnou licencí a zdarma!

V současné době jsou hlavním tématem v mnoha společnostech úspory. Není vůbec snadné prosadit jakýkoliv nový projekt. Na druhou stranu ICT prostředí je vystavováno stále větším nárokům a rozrůstají a zvyšují se i požadavky na jeho bezpečnost. Pomocníkem v této situaci je Identity management, který spravuje uživatelské účty, role, skupiny, organizační zařazení a jejich vztah k jednotlivým aplikacím a datům. Jak tedy nasadit centrální správu identit, bez velkých výdajů za licence a s využitím vlastních pracovníků?

bcv

Společnost BCV solutions s.r.o., leader v oblasti Identity a Access Managementu, nabízí pomocnou ruku. Po dlouhých letech vývoje a vylepšování svého identity manageru CzechIdM, který spravuje již více než 2 000 000 účtů, přibližuje na českém trhu řešení IDM každému. CzechIdM je nyní dostupné pod svobodnou licencí a zdarma! Proč se k tomuto kroku naše společnost přiklonila?

„Již od založení společnosti v roce 2008 bylo naším cílem především pomáhat firmám se správou identit. Poptávka po CzechIdM dlouhodobě překračuje naše možnosti. Protože chceme držet kvalitu implementací projektů, kontrolujeme náš růst.  Rozhodli jsme se dát CzechIdM k dispozici zdarma pod svobodnou licencí všem, kdo potřebují kvalitní a prověřené řešení IDM,” říká Lukáš Cirkva, ředitel společnosti BCV solutions s.r.o.

 

czechidm

 

Může CzechIdM pomoci právě Vám?

CzechIdM zajišťuje kompletní řešení správy uživatelských účtů pro malé a střední společnosti, instituce státní správy a zdravotnická zařízení. Toto řešení se tak stává dostupnější alternativou k již existujícím produktům společností Oracle, IBM či Novell.

Kdokoliv si produkt CzechIdM stáhne, je schopen jej nainstalovat, snadno připojit systémy a především jej používat,“ doplňuje Lukáš Cirkva.

Pokud vás řešení CzechIdM zaujalo a máte zájem o více informací či instalační soubory, navštivte nás na www.czechidm.com.

O BCV solutions

BCV solutions s.r.o., česká společnost se sídlem v Praze se zaměřením na poskytování IT řešení a služeb. Pomáháme zlepšit Identity a Access Management. Aktuálně zákazníkům pomáháme spravovat přes 2.000.000 účtů!

Kontakt

Lukáš CIRKVA, CEO
tel.: +420 724 111 809
email: lukas.cirkva@bcvsolutions.eu
http://www.bcvsolutions.eu

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 Jan.Effenberger@bcvsolutions.eu

 

9 důvodů, proč dát přednost CzechIdM před Oracle Waveset

V poslední době se mě na prezentacích a školeních čím dál častěji ptají, v čem je náš Identity Management CzechIdM lepší než dosluhující Oracle Waveset, dříve nazývaný též Sun Identity Manager. Jako projektový manažer i vývojář jsem se na vlastní kůži setkal s oběma; nedávno jsem tu psal o úspěšné migraci z Oracle Waveset na CzechIdM ve Všeobecné fakultní nemocnici. Můžu tedy srovnávat, důvodů k migraci je celá řada.

  1. Podpora – CzechIdM je svým tvůrcem stále rozvíjeno.
    Zatímco Oracle Waveset je jako produkt mrtvý, CzechIdM se vyvíjí podle požadavků zákazníků, reaguje na technologické trendy a přizpůsobuje se novým verzím napojovaných systémů.
  2. Otevřené zdrojové kódy – Pokud máte Waveset, máte černou skříňku.
    S Wavesetem jste si nainstalovali předkompilované binární soubory, které si nepřečtete ani nepřizpůsobíte. Zákazníci CzechIdM naproti tomu dostanou kompletní zdrojové kódy a je na nich, zda budou chtít něco upravit.
  3. Příjemnější rozhraní – uživatelé mají raději CzechIdM.
    Rozdíl je v detailech: jednodušší menu, větší tlačítka, smysluplnější popisky, méně klikání v obvyklých situacích, přehlednější nápověda…
  4. Méně práce pro vývojáře – přizpůsobit CzechIdM je rychlejší a stojí to méně peněz.
    Kdo někdy programoval pro Oracle Waveset, dá mi za pravdu: napsat jednoduchý proces pro Waveset znamená naučit se podivný jazyk XPress a napsat v něm tisíc řádků kódu. CzechIdM používá standardní Javu, pokud jste se s ní potkali aspoň na gymnáziu, nejspíš byste zvládli napsat svůj první proces pro CzechIdM ještě dnes. Zákazník tak ušetří přes 30% nákladů.
  5. Výkon – CzechIdM zvládne za stejný čas více práce.
    Waveset drží všechny své objekty v XML struktuře. CzechIdM má datový model chytřejší: využívá všech výhod moderních relačních databází. Díky tomu pracuje s uživateli, účty a rolemi rychleji a efektivněji.
  6. Bezpečnost – tvůrci CzechIdM reagují na rizika.
    Ve světě informačních systémů se každý rok objevují nová bezpečnostní rizika – v databázích, aplikačních serverech, programovacích jazycích… Zatímco programátoři CzechIdM novým slabinám v technologiích čelí (viz nedávno odhalená bezpečnostní chyba v MySQL, na kterou museli reagovat, http://blog.sucuri.net/2012/06/security-vulnerability-in-mysql.html), Waveset už jen stojí na místě: bezpečnostní díra u něj zůstane dírou navždy..
  7. Jednodušší pro administrátory – s CzechIdM se administrátor rychleji naučí pracovat
    CzechIdM má jen ty funkce, které jsou skutečně potřeba. Administrátor tak může hned dělat svou práci a netráví dlouhý čas studiem nového produktu. Kompletní dokumentace v češtině taky není k zahození.
  8. Lokální tvůrce – tým vývojářů v Česku
    Na rozdíl od Wavesetu je CzechIdM stoprocentně český produkt vyvinutý lokální společností. Když zákazník potřebuje pomoc, dorazí k němu expert, který CzechIdM sám vytvářel a zná produkt do posledního řádku kódu.
  9. Prezentační vrstva na míru – JSF vs. XPress
    Složitější formulář pro Waveset jsou 3 dny práce v jazyce XPress a výsledek pravděpodobně nebude úplně podle vašich představ. CzechIdM stejně jako většina dnešních aplikací používá JSF, formulář bude za odpoledne a po stránce vzhledu je realizovatelné prakticky cokoli.

Ano, mít důvodů deset, vypadalo by to lépe. Máte podobnou zkušenost jako já? Pomůžete nám vymyslet desátý důvod? Kontaktovat nás můžete na adrese 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 jan.effenberger@bcvsolutions.eu.

Laserový teambuilding

Minulý týden jsem brouzdal po internetu a po dlouhé době má cesta vedla na známý slevový portál. Mezi záplavou pro mě nezajímavých slev jsem narazil na jednu, která mě přímo „praštila do očí“.  LaserGame! Perfektní! Jak jsem na to mohl po dlouhá léta zapomínat? Hned kupuji…. počkat! ale s kým pujdu?  Odpověď byla jasná, oslovím kolegy a  podnikneme LaserGame jako formu tzv. „teambuildingu“. Sedl jsem tedy k počítači a rozeslal hromadný mail (ano ten typ mailu kteří všichni tolik nesnáší). Reakce byla okamžitá a během prvních 2 hodin se zaregistrovalo 6 dalších lidí.  OK team bychom měli. Vouchery jsem zakoupil a zarezervoval termín.

V den D byla cítit soutěžní nervozita v celé firmě, všichni si chtěli zastřelit svého šéfa! Večer jsme se sešli na místě konání v Plzeňské ulici, kousek od Smíchova. 2 hodiny předem. Rozhodli jsme se tedy usadit přímo v aréně kde podávají i orosené, chlazené občerstvení. Samozřejmě nemohlo chybět ani klasické nabrání sil v podobě nejvýznamnějšího přínosu světu z Itálie, známého božského kulatého zázraku.obrázek 1-resized

22:00 náš čas nadešel! Obléknout vesty a připravit zbraně. Vbíháme do arény a očekáváme zahajovací signál. Nutno dodat, že v zájmu větší „řeže“ jsme se rozhodly pro hru ve stylu „free for all“, tzn. všichni proti všem. V tomto módu prostě nemáte žádné přátele.

obrázek 2

Je tu signál! všichni začínáme sprintovat po aréně a kolem nás zběsile létají lasery. Pálíme po všem co se pohne nezávisle na pohlaví, věku nebo vzrůstu. Často se stává že zaběhnu za roh a srazím se s kolegou. No nevadí, i když leží na zemi, stále je to terč! Atmosféru dokresluje osvětlení, futuristické zvuky laserů a umělá mlha.

Konec! po 15 minutách, které nám připadali jako věčnost končíme. Jsme strašně spocení, ulítaní a plní adrenalinu. Jdeme se vyfotit a následuje vyhodnocení. Úděl šéfa je znát, ten náš končí na posledním místě :), prostě si chtěl každý vystřelit.

obrázek 3-resized

Chladneme u dalšího zlatavého moku a vyhodnocujeme hru. Padá rozhodnutí, že příště zkusíme něco realističtějšího a že se máme na co těšit, dnes jsem pro náš team zakoupil vouchery na paintball. O fotky (náležitě barevné)  a report jistě nepřijdete!

Jaký nejlepší teambuilding jste zažili vy? Napište mi to na Facebooku :)

 

 

 

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.

Firemní teambuilding na horách v Rokytnici nad Jizerou

Již nějakou dobu jsme přemýšleli, jak dát kolegům více možností poznat se navzájem a strávit spolu i nějaký čas mimo kancelář.
Jeden z nápadů byl společný firemní víkend na horách. První termín na začátku ledna byl z důvodu špatného počasí zrušen. Přesto jsem velmi rád, že se nám podařilo najít další vhodný termín a zájezd na hory uskutečnit.

IMG_3826-resized

Jako výchozí místo jsme si vybrali Rokytnici nad Jizerou, díky příhodné pozici pro výlety na hřebeny Krkonoš. Počasí v Rokytnici bylo značně nevlídné, pršelo a foukalo. Přesto jsme se rozhodli vyrazit směr Lysá hora -> Kotel -> Labská bouda.

Postupně s přibývající nadmořskou výškou se déšť měnil na sněžení. Ve chvíli, kdy jsme dosáhli vrcholu Lysé hory, jsme poznali sílu hor ve formě hustého sněžení, velmi silného větru a minimální viditelnosti. Mlha se na chvíli zvedla, tak jsme rychle zdokumentovali naší přítomnost na Kotli (úvodní fotka). Jistě si všimnete, že na úvodní fotce vypadáme všichni velmi čerstvě a jsme ještě nadšení z celého výletu. Postupem času se to bude vlivem únavy a především šíleného počasí rychle měnit, ale nepředbíhejme.

Po dosažení Kotle jsme se stočili směrem k pramenům Labe. Po překonání sedla Lysá hora – Kotel nám počasí ukázalo svou krutou tvář. Vítr značně zesílil, chůze byla velmi obtížná, bez patřičné výbavy (maska + brýle) nebylo skoro možné koukat se přímo. Šli jsme v řadě za sebou. Kromě prvního měli všichni pohledy upřené k zemi. Když si na to teď vzpomenu, vypadali jsme jako zasněžení tučňáci :). Po několika kilometrech chůze v nepřízni počasí se před námi objevil nouzový přístřešek, kde jsme se schovali před větrem a sněžením a posvačili. Bohužel bylo znát, že je to jediný podobný přístřešek v okolí, záhy bylo plno a tak jsme byli nuceni pokračovat dál.

Po několika dalších kilometrech jsme došli k Labskému vodopádu (kde se někteří propadli do Labe). A konečně, Labská Bouda! Vytoužený krátký odpočinek a následovala nejnebezpečnější část trasy zpět na Kotel.

IMG_3840-resized

Mlha se pomalu zvedala a tak se nám otevíraly krásné pohledy do okolí. Vlivem mlhy jsme si bohužel nevšimli značek o lavinovém nebezpečí a krátili si cestu po lavinovém svahu. Hory se nad námi slitovaly a nechali nás dojít až na Vrbatovu boudu, kde jsme si opět na chvilku oddechli. Teď už jen seběhnout sedlem na Dvoračky a poté kolem Huťského potoka až do Rokytnice a bylo to za námi.

IMG_3831-resizedIMG_3833-resizedIMG_3832-resized

V létě nebo za dobrého počasí se tento okruh dá urazit za 3 hodiny. Díky špatné viditelnosti a šílenému větru jsme šli trasu zhruba 8 hodin!
Tímto smekám před všemi, kdo se účastnili této procházky, a děkuji, že jsme nikoho nemuseli zpět nést. :)

Pro příště už víme, že můžeme ještě přitvrdit a vybrat nějakou pořádnou trasu, třeba ve Vysokých Tatrách nebo v Alpách.

Pomáháme spravovat přes 2 000 000 účtů!

Je mi potěšením Vám oznámit, že jsme v lednu 2014 zdolali další magickou hranici v počtu spravovaných účtů na napojených systémech. K dnešnímu dni CzechIdM a Sun IdM u našich zákazníků pracuje s neuvěřitelnými 2 204 122 účty napříč všemi segmenty trhu: pomáhá ve zdravotnictví, ve školství, ve státní správě i v soukromém sektoru.

pocitadlo

Pokračování textu

Nabízíme nemocnicím pomoc s certifikáty – produkt eCert

Aktuálně stojí IT oddělení nemocnic před bezpochyby velkým úkolem a to zavedením elektronických receptů (tzv. eReceptů). Vzhledem k očekávanému termínu zavedení prvního ledna 2015, je již nejvyšší čas danou problematiku řešit. Dají se ovšem procesy se zavedením a používáním eReceptů při stovkách až tisících lékařů či sester nějak automatizovat a tím podstatně zjednodušit a zrychlit?

Logo-eCerT

Na základě desítek osobních schůzek a rozhovorů s odpovědnými osobami v nemocnicích jsme vyvinuli specifický produkt eCert, který významnou měrou usnadní a ulehčí zavedení a správu elektronické zdravotní dokumentace.
Produkt pomáhá ve Všeobecné fakultní nemocnici v Praze.

Automatizace životního cyklu certifikátu nemocnicím ulehčí a zrychlí celý proces žádosti, vydání, používání a případně i revokace certifikátu. Již není nutné aby lékaři stáli opakovaně fronty na poště a čekali ve frontách. Pomocí eCert si podají žádost o certifikát jediným kliknutím. Potom je nutné osobně ověřit svou totožnost (toto je ze zákona povinné) na pracovišti certifikační autority.  Po vydání certifikátu si lékař již jen vyzvedne privátní část klíče na tzv. tokenu a může okamžitě podepisovat zdravotnickou dokumentaci. O všechny ostatní procesy se postará eCert spolu s certifikační autoritou.

Chcete-li i Vy ulehčit a zrychlit procesy spojené s elektronickou zdravotní dokumentací, neváhejte nás kontaktovat na info@bcvsolutions.eu a navštívit web www.ecert.cz. Uděláme maximum abychom Vám pomohli.