Archiv pro rubriku: Programování

Archiv v CzechIdM

Potřebovali jste si někdy něco zazálohovat? Případně potřebovali jste si udržovat změny ohledně nějakého objektu v průběhu času? Jestli ano, nyní je to v CzechIdM možné. V CzechIdM vznikl nový modul — archiv, který zvládá tyto úkony a ne jenom to. Vše o principu a správném použití archivu si můžete přečíst právě v tomto článku.

Pokračování textu

Vypisujeme témata pro bakalářské a diplomové práce

Již několik let vypisujeme témata a vedeme bakalářské a diplomové práce. Zadání vytváříme na základě reálné potřeby pro skutečné zákazníky. Výsledek Vaší práce bude někdo používat a to v podstatě ihned. Proto hledáme šikovné lidi, kteří se nebojí udělat pořádnou práci a mají zájem se trochu zviditelnit.

Na čem budete pracovat?

CzechIdM Identity Management – nástroj pro centralizaci a automatizaci správy uživatelských identit (účtů, skupin atd.) v celé síti, a to bez výrazných zásahů do fungování stávajících systémů. CzechIdM je SW kompletně naprogramovaný v jazyce Java, konkrétně na platformě J2EE. Více zde: http://www.czechidm.com

Co budeš používat?

  • Java EE
  • JBoss AS
  • JBoss jBPM
  • Hibernate, Java persistent API (JPA)
  • Java Server Faces, Richfaces framework
  • EJB3
  • Connector Framework

Koho hledáme?

Obecně hledáme toho, kdo chce něco smysluplného vytvořit. Chceme toho, kdo dokončí co začal a chce se svou prací dlouhodobě chlubit. Pokud máte zájem vytvořit kvalitní práci, která nebude do šuplíku, a která bude přínosem, kontaktujte nás.

Ukázka témat

  1. Vytvoření konektoru na připojení Office365.
  2. Vytvoření automatické testovací platformy a automatických testů na GUI.
  3. Vytvoření nového uživatelského rozhraní CzechIdM.
  4. Realizace databázového migrátoru.

Kontakt

Kontaktuj mne na mailu lukas.cirkva@bcvsolutions.eu. Následovat bude osobní schůzka, kde si popovídáme a nabídneme několik témat a pokud si plácneme, domluvíme další kroky.

První krůčky s CzechIdM Kapitola 3: Nastavení synchronizace a rekonciliace systému

czechidm

V minulém díle jsme si ukázali, jak vytvořit koncový systém pro CzechIdM, a jak s jeho pomocí spojit CzechIdM s databázovou tabulkou. Dnes si ukážeme, jak sesynchronizovat účty v koncovém systému s identitami v CzechIdM. Také nastavíme rekonciliaci. Rozdíl mezi těmito dvěma slovy není veliký, protože obě operace se starají o stejnou činnost, jen v jiném rozsahu. V obou situacích sjednocujeme (synchronizujeme) stav účtů na koncovém systému a informace, které o nich máme v CzechIdM. A právě takovou operaci si dnes ukážeme. Ale nejdříve si vysvětlíme, co se vlastně při synchronizaci nebo při rekonciliaci děje.

Co to je synchronizace a rekonciliace

Jak jsme si již řekli o odstavec výše, cílem obou operací je synchronizovat data na koncovém systému a v CzechIdM. To se hodí provést v různých situacích. Buď jde o koncový systém, který jsme nově napojili na CzechIdM, a chceme účty na tomto systému připárovat k identitám v CzechIdM. Nebo jde o autoritativní koncový systém, kde pravidelně vznikají, aktualizují se nebo zanikají účty, a při každé takové změně chceme náležitě vytvořit, upravit či smazat příslušnou identitu v CzechIdM. Případně jde prostě o systém, kde z nějakého důvodu nesouhlasí stav účtů s tím, co je evidováno v CzechIdM, a to chceme opravit.

Zatímco při synchronizaci se zpracovávají jen ty účty na koncovém systému, které se od poslední synchronizace změnily nebo nově vytvořily, při rekonciliaci se zkontrolují úplně všechny účty. Samozřejmě nemusíme každých deset minut spouštět vybranou operaci ručně. Stačí jednou nastavit, kdy se má synchronizace či rekonciliace spustit a jak často se má opakovat.

Tím ale možnosti nastavení nekončí. Při obou operacích si můžeme vybrat, co se stane, nastane-li nějaká z modelových situací. Například představme si situaci, kdy vznikne nový účet na koncovém systému. Pomocí synchronizace můžeme nastavit, jaká operace se má provést. Můžeme si vybrat, co se stane jako výkonná akce a co jako informativní akce. Tak například jako výkonnou akci můžeme nastavit vytvoření nové identity, a jako informativní odeslání e-mailu na námi zadanou adresu. Samozřejmě pokud si nechceme zahlcovat schránku, CzechIdM nám může zaslat zprávu pouze v případě, kdy dojde k nějaké chybě, a nebo nám nemusí zasílat zprávy vůbec. Představivosti se meze nekladou.

Zasílání zpráv není rozhodně jedinou věcí, kterou CzechIdM umí. Můžeme si například nastavit hromadnou akci, která se spustí po zpracování všech účtů synchronizací/rekonciliací. Buďto můžeme opět odesílat zprávy, nebo si můžeme vybrat nějaké workflow či pravidlo, které se vykoná.

Důležitá věc, kterou musíme každé synchronizaci/rekonciliaci nastavit, je korelace. Korelace je podmínka, podle které CzechIdM přiřazuje jednotlivým identitám odpovídající účty. Například pokud jsme si v minulém dílu nastavili login jako jedinečný identifikátor účtu na koncovém systému, zde ho můžeme použít v nastavení synchronizace/rekonciliace: na základě rovnosti loginu koncového účtu a názvu identity v CzechIdM se účet této identitě přiřadí.

Zde jsou vyjmenované jednotlivé možnosti, které při synchronizaci či rekonciliaci mohou nastat:

  • ASSIGNED – účet je již přiřazen konkrétní identitě
  • MATCHED – účet a identita si odpovídají na základě korelace, ale účet ještě není připárován k identitě
  • 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.

Tak nyní bychom měli mít alespoň základní informace o tom, co se vlastně při synchronizaci a rekonciliaci děje, a pojďme přejít na jejich nastavení.

 

Nastavení rekonciliace/synchronizace

Jako první krok si ukážeme, jak namapovat atributy.

Namapování atributů je potřebné v případě, kdy se během synchronizace/rekonciliace mají nastavovat hodnoty atributů identity v CzechIdM. Využijeme to tedy především u autoritativních koncových systémů. Například nastavíme, že do atributu „email“ u identity v CzechIdM se bude propagovat hodnota atributu „email“ koncového účtu. Pro rekonciliace běžných koncových systémů obvykle stačí nastavit mapování atributu „roles“, tj. jak se mají aktualizovat role identity v CzechIdM.

Přejdeme tedy na:

SystémyMapování atributů

1

vyplníme atributy identity a Uložíme výsledek.

2

Nyní přejdeme k nastavení samotné rekonciliace. Nastavení synchronizace je úplně stejné, proto si zde ukážeme pouze nastavení rekonciliace. Přejdeme na:

Systémy → Systémy → Nastavit rekonciliaci

1

u systému SystemTest1.

Zde nastavíme jednotlivé výkonné a informativní akce pro všechny stavy rekonciliace. 

42

a následně klikneme na Uložit.

Zobrazení výsledku rekonciliace/synchronizace

Zde si ukážeme, jak si zobrazit informace o probíhající rekonciliaci.

3

Přejdeme na:

Systémy → Systémy → Zobrazit informace o rekonciliaci (SystemTest1)

4

Zde jsou uvedeny informace o probíhající rekonciliaci, případně o posledním průběhu. Po prvním provedení se nelekejte výsledků MISSING_IDENTITY. Důvod je jednoduchý, jelikož proběhla první rekonciliace, nebyly v CzechIdM ještě žádné identity, které koncovým účtům odpovídají. Proto CzechIdM zahlásilo, že identita chybí, a vytvořilo ji. Pro odchod stačí kliknout na tlačítko Zavřít.

Závěr

V tomto krátkém díle jsme si ukázali, jak nastavit synchronizaci a rekonciliaci na CzechIdm. Po nastavení a spuštění by měly být všechny naše účty aktuální.

V případě jakýchkoliv dotazů pište prosím na michal.stejskal@bcvsolutions.eu.

 

První krůčky s CzechIdM Kapitola 2: Připojení databázové tabulky

czechidm

V tomto díle našeho krátkého seriálu o práci v CzechIdM se podíváme na to, jak definovat konektor pro koncový systém, jak připojit námi vytvořenou tabulku ke koncovému systému a nakonec se podíváme, jak vytvořit roli pro náš koncový systém.

Vytvoření databázové tabulky

V minulém dílu jsme si nainstalovali MySQL, zatím ale stále nemáme žádné přívětivé prostředí, kde můžeme s databázemi pracovat. Proto si nainstalujeme MySQL workbench. Instalace tohoto prostředí není nijak složitá, stačí v terminálu zadat

$sudo apt-get install mysql-workbench

Po skončení instalace zadáme opět v terminálu mysql-workbench

  • Ze záložky Database vybereme možnost Manage Connection. Zde pojmenujeme naše připojení a klikneme na Test connection. Pokud nastali problémy, zkontrolujte si prosím parametry připojení:

Záložka Connection

Connection Method: Standard (TCP/IP)

Hostname: 127.0.0.1

Port: 3306

Username: root

  • Ze záložky Database vybereme Connect to Database. U možnosti Stored Connection vyberem námi vytvořené připojení a klikneme na OK.
  • Zobrazí se nám prostředí pro práci s databázemi. Uprostřed je bílé okno pro vykonávání SQL příkazů. Do něj zadáme:
CREATE SCHEMA `test` ;
CREATE TABLE test.datas (
`ID` INT,
`firstName` TEXT,
`lastName` TEXT,
`login` TEXT,
`address` TEXT,
`city` TEXT,
`dateOfBirth` TEXT,
`company` TEXT,
`possition` TEXT,
`salary` INT,
`timeStamp` TEXT);

a klikneme na žlutý blesk v horní části obrazovky. Tím se vykoná SQL příkaz, který vytvoří nové schéma test a v něm tabulku datas se sloupci jméno, příjmení, email… .

  • Dalším krokem je nastavení primárního klíče. V levé části obrazovky máme světle modré pole. Pokud máme mysql-workbench spuštěný poprvé, je toto pole prázdné. Klikneme na něj tedy pravým tlačítkem a vybereme Refresh All. Zobrazí se námi vytvořené schéma a v něm naše zatím prázdná tabulka.
  • Klikneme na ní opět pravým tlačítkem a zvolíme Alter table. Otevře se nám dialog pro nastavení tabulky test. Zaškrtneme parametry PK a NN u sloupce ID. Parametr PK znamená, že daný sloupec bude primárním klíčem. Pomocí primárního klíče se jednoznačně identifikuje každý záznam v tabulce. To znamená, že žádné ID v naší tabulce nemůže být shodné s dalším, nebo že žádné ID nesmí být prázdné. Toho docílíme právě zaškrtnutím NN parametru (nut null). Dále zaškrtneme možnost AI (Auto Increment), kterým nastavíme, že každé další ID bude o jedna větší než ID předchozí.
  • Nyní nasypeme nějaká testovací data do naší nové tabulky. Do záložky Query 1 v horní části obrazovky  zkopírujeme následující kód:
INSERT INTO test.data (`firstName`, `lastName`, `login`, `address`, `city`, `dateOfBirth`, `company`, `possition`, `salary`, `timeStamp`) VALUES ('Drahoslav', 'Miler', 'Drahoslav@Miler.cz', 'Stráň 122', 'Lobeč', '10.10.1957', 'b', 'Lorem ', '20077', '12.4.2014');

Opět klikneme na žlutý blesk vlevo nahoře do naší databáze se přidá první záznam. Takto můžeme vkládat kolik záznamů chceme. Vždy do hodnoty VALUES vložíme data přesně tak, jak je to ukázáno v kódu nahoře. Pokud si chceme zkontrolovat výsledek, klikneme pravým tlačítkem myši na tabulku datas a zvolíme Select rows – 1000 limit.

Pokud si o databázích chcete přečíst něco podrobnějšího, podívejte se například na tento seriál: http://www.linuxsoft.cz/article.php?id_article=731

Definování typu systému pro konektor

Prvním krokem je vydefinování typu systému pro Database Table konektor v CzechIdM. Tento krok stačí provést pouze jednou, a to když připojujete nějaký systém pomocí tohoto konektoru poprvé. Přejdeme tedy na záložku

Systémy → Typy systémů → Nový typ.

Zaškrtneme možnost, že se má použít lokální connector server a klikneme na Pokračovat. Posledním krokem je pojmenování nového typu systému a vybrání správného balíku. My náš typ pojmenujeme Database Table Konektor a jako balík vybereme org.identityconnectors.databasetable-1.1.xx.jar.

Nyní stačí už jenom náš nový typ systému uložit a máme hotovo.

Připojení systému s databázovou tabulkou

Snímek obrazovky pořízený 2014-07-27 23:06:42

Nyní již propojíme námi vytvořenou tabulku s CzechIdM. Pro tento krok musíme vytvořit nový systém, který bude sloužit k připojení k tabulce. Přejděme tedy na záložku

Systémy → Systémy → Nový systém
  • Vybereme konektor, který jsme vytvořili v předchozím kroku, tedy Database Table Konektor a klikneme na Next.
  • V nové tabulce vyplníme Název systému na SystemTest1, kolonku Název pro uživatele necháme v tuto chvíli volnou.
  • Authority level nastavíme na 0. Tímto číslem určujeme jak moc bude náš systém autoritativní pro data v CzechIdM. Čím je toto číslo větší, tím více je systém autoritativní. Prakticky to bývá tak, že level 1 je zdrojový systém (systém je zdroj dat pro identity v CzechIdM), level 0 je koncový systém (CzechIdM je zdroj dat pro koncový systém).
  • Pouze ke čtení nebudeme zaškrtávat, protože budeme v budoucnu upravovat tabulku pomocí CzechIdM.
  • Další položkou, kterou vyplníme, je port. Nastavíme ho na 3306, tam nám totiž běží MySQL databáze.
  • Dále jako Key Column zvolíme login. Key Column nám určuje, který atribut bude použit jako identifikátor jak při zobrazování, tak i například při synchronizaci systému.
  • Initial JNDI Properties v tuto chvíli necháme volné.
  • Do položky Host zadáme místo, kde nám běží server, tedy localhost.
  • All native nebudeme zaškrtávat.
  • Name quoting necháme volné.
  • Do políčka Table zadáme jméno námi vytvořené tabulky, tedy datas.
  • Pokud jste nechali při instalaci MySQL serveru políčko pro heslo roota prázdné, nevyplňujte ani políčko User Password. V opačném případě zadejte heslo, jež jste si nastavili pro MySQL roota.
  • Do kolonky Database se zadává jméno databáze, ke které se připojujeme. V našem případě se databáze jmenuje test.
  • Change Log Column (Sync) nastavíme na timeStamp. Tím jsme nastavili, který atribut bude použit při synchronizaci systémů jako časová značka změněných řádků.
  • Password Column necháme také volné, protože v naší databázové tabulce nemáme žádný sloupec obsahující hesla.
  • JDBC Connection URL nastavte na jdbc:mysql://%h:%p/%d. Tím jsme určili URL pro spojení CzechIdM a databáze.
  • Native Timestamps a Enable writing empty string nebudeme zaškrtávat, ale položku Rethrow all SQLExceptions označíme.
  • Validate Connection Query necháme volné.
  • Do pole User napíšeme root, což je uživatelské jméno, přes které se připojujeme k MySQL databázi.
  • Datasource Path necháme volné.
  • JDBC Driver nastavíme na com.mysql.jdbc.Driver. Tím jsme určili třídu konektoru pro připojení do databáze.

Nyní klikneme na tlačítko Test. Tím se otestuje zda-li je náš systém pro připojení správně nastaven. Zobrazí-li se hláška o úspěšném navázání spojení, klikněte na Pokračovat.

Snímek obrazovky pořízený 2014-07-27 23:08:06

Nyní se dostaneme do okna, kde můžeme editovat atributy. Klikneme tedy na Editovat atributy a zobrazí se nám jména sloupců z námi vytvořené databázové tabulky.  Do sloupce IdmName vyplníme jednotlivé atributy tak, aby CzechIdM poznalo, o který atribut se jedná, Tedy pokud pojmenujeme atribut firstName, pro CzechIdM opět firstName, CzechIdM bude vědět, že se jedná o křestní jméno. Poté klikneme na tlačítko Uložit.

Pokud si chceme zobrazit výsledky naší práce, klikneme na na odkaz Zobrazit všechny účty na seznamu našich systémů. Měli bychom vidět pouze prázdný seznam a až po kliknutí na tlačítko Hledat se nám zobrazí všechny účty z našeho koncového systému. Můžeme rozklikávat jednotlivé účty a prohlížet si jejich detaily. Ve chvíli, kdy skončíme, klikneme na tlačítko Zavřít.

Vytvoření role pro připojený systém

Poslední krok, který si v tomto článku ukážeme, je vytvoření role v CzechIdM, která vytváří účty na připojeném systému, jakmile je přiřazena uživateli. Přejdeme na záložku

Role → Role → Nová role

a zde na záložce Základní informace vyplníme název nové role (např. Test system account). Poté přejdeme na záložku Schémata zdrojů a klikneme na odkaz Přidat u systému Test end system v pravé tabulce (se seznamem všech připojených systémů). Poté klikneme na odkaz Editovat v levé tabulce (se seznamem systémů, ke kterým opravňuje tato role).

Na následující stránce můžeme nastavit, jak budou atributy účtu plněny touto rolí v závislosti na svých potřebách. Zatím to ponecháme beze změny a klikneme na Nastavit.

Naši novou roli už jen Uložíme. Tuto roli můžeme přidělit libovolné identitě a tím pro ni vytvořit nový účet na napojeném koncovém systému.

Závěr

V tomto článku jsme si ukázali, jak připojit databázovou tabulku pomocí Database Table konektoru, a jak si zobrazit data z tabulky. Dále jsme si ukázali, jak vytvořit roli, jež nám vytvoří účet pro identitu v databázové tabulce. V příštím díle se podíváme na to, jak sesynchronizovat účty a jak nastavit rekonciliaci.

Pokud jste v článku nalezli nějakou chybu, nebo máte nějaký dotaz, prosím napište mi na michal.stejskal@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.

Jak zabezpečit Liferay portál pomocí HTTPS

Pro našeho zákazníka jsme implementovali portlet pro zabezpečené přihlášení do jeho interních aplikací. Tento portlet je umístěn na Liferay portálu a po ověření loginu a hesla proti Access Manageru SunSSO (technologii popsal kolega zde) vydá uživateli SSO cookie. Součástí tohoto úkolu bylo zabezpečit Liferay portál, aby k přihlašovací stránce šlo přistupovat pouze pomocí HTTPS. Na druhou stranu bylo nutné, aby k jiným stránkách portálu bylo možné nadále přistupovat přes HTTP.

V tomto článku vás seznámíme se způsobem, jak jsme tento požadavek vyřešili.

Analýza prostředí

V prostředí našeho zákazníka běží portál Liferay 6.1.2 CE na aplikačním serveru Tomcat 7.0.40.

Jedno z řešení, které bychom mohli použít, by spočívalo v nastavení HTTPS přímo do konfigurace Tomcatu. Druhou možností bylo nainstalovat před Liferay web server, který se postará o zabezpečení přes SSL a požadavky bude lokálně předávat aplikačnímu serveru již nešifrovaně.

Zvolili jsme druhý přístup, protože umožňuje větší flexibilitu a i do budoucna snazší řešení specifických požadavků zákazníka. Vybrali jsme Apache web server, který bude poskytovat následující služby:

  • Na portu 80 bude poskytovat přístup k Liferay portálu přes HTTP.
  • Na portu 443 bude poskytovat zabezpečený přístup k Liferay přes HTTPS. Pro ověření pravosti serveru bude nabízet certifikát uložený na serveru.
  • Přistoupí-li uživatel přes HTTP, zůstane po celou dobu na nezabezpečeném kanálu. Podobně pro HTTPS – po prvním přístupu na HTTPS už na něm uživatel zůstane. Není žádoucí vyžadovat jen zabezpečený přístup.
  • Předchozí bod má jednu výjimku, a to u stránky pro přihlášení. Zde je vždy vynucen přístup přes HTTPS.

Pro zajištění všech uvedených služeb stačí do standardní instalace Apache přidat ještě modul mod_ssl.

Nastavení Apache

Web server Apache a modul mod_ssl jsme nainstalovali ze standardních balíčků operačního systému CentOS:

$ yum install httpd
$ yum install mod_ssl

Dále ověříme, že jsou přítomné moduly mod_proxy a mod_proxy_ajp (na CentOSu jsou součástí standardní instalace Apache). Pokud nejsou, nainstalujeme je podobně jako mod_ssl.

Instance Apache je umístěna v adresáři /etc/httpd. Zde vytvoříme adresář ssl, kam umístíme náš certifikát a jeho soukromý klíč (mujweb.cz.cert a mujweb.cz.key).

Konfiguraci portů chceme mít umístěnou v jednom souboru, proto v hlavním konfiguračním souboru v conf/httpd.conf zakomentujeme řádek Listen 80. Ve složce conf.d přidáme ke všem konfiguračním souborům např. příponu „.orig“, aby je Apache nenačítal (případně je můžeme rovnou smazat).

Následně vytvoříme hlavní konfigurační soubor v adresáři conf.d:

LoadModule ssl_module modules/mod_ssl.so
Listen 80
Listen 443
SSLPassPhraseDialog builtin
SSLSessionCache "shmcb:/var/run/ssl_scache(512000)"
SSLSessionCacheTimeout 300
SSLMutex "file:/var/run/ssl_mutex"

<VirtualHost mujweb.cz:80>
    ServerName mujweb.cz

    <IfModule mod_proxy.c>
        ProxyRequests Off
        ProxyVia On
        <Proxy *>
            Order Allow,Deny
            Allow from All
        </Proxy>
        <LocationMatch "/web/login">
            Redirect permanent / https://mujweb.cz/
        </LocationMatch>
        ProxyPass / ajp://localhost:8009/
    </IfModule>
</VirtualHost>
<VirtualHost mujweb.cz:443>
    ServerName mujweb.cz

    <IfModule mod_proxy.c>
        ProxyRequests Off
        ProxyVia On
        <Proxy *>
            Order Allow,Deny
            Allow from All
        </Proxy>
        ProxyPass / ajp://localhost:8009/
        </IfModule>

        SSLEngine on
        SSLProtocol -ALL +SSLv3 +TLSv1
        SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
        SSLCertificateFile "/etc/httpd/ssl/mujweb.cz.cert"
        SSLCertificateKeyFile "/etc/httpd/ssl/mujweb.cz.key"
        SSLVerifyClient none

        <FilesMatch "\.(cgi|shtml|phtml|php)$">
            SSLOptions +StdEnvVars
        </FilesMatch>

        BrowserMatch ".*MSIE.*" \
        nokeepalive ssl-unclean-shutdown \
        downgrade-1.0 force-response-1.0

        ErrorLog "logs/httpd-error.log"
        TransferLog "logs/httpd-access.log"

        CustomLog "logs/httpd-ssl_request.log" \
            "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

Všimněme si zvýrazněných řádků. První z nich zajistí, že při přístupu na přihlašovací stránku (http://mujweb.cz/web/login) je uživatel ihned natrvalo přesměrován na HTTPS. Řádek s direktivou ProxyPass / ajp://localhost:8009/ zajišťuje předávání požadavků do Liferay, čímž se podrobněji zabývá následující kapitola.

Nyní zbývá už jen nastartovat Apache a také nastavit, aby se automaticky spouštěl při každém restartu serveru:

$ service httpd start
$ chkconfig --level 2345 httpd on

Samozřejmostí, na kterou ale snadno zapomeneme, je, aby porty 80 a 443 byly povolené ve firewallu :-)

Nastavení Liferay

Tomcat běží standardně na portu 8080, kde poskytuje stránky portálu. Zároveň ale na portu 8009 poslouchá jeho AJP konektor, který je určen ke komunikaci aplikačního serveru s web serverem. Požadavky na web server proto směřujeme na tento port, což zajistí, že Liferay dostane informaci o tom, jakým způsobem uživatel přistupuje. Liferay tuto informaci potřebuje zejména kvůli generování odkazů v rámci portálu (např. odkazy, kam se odesílají formuláře). Musí vědět, zda má vygenerovat odkaz pro HTTP, nebo HTTPS, či jaké má použít hostname.

V konfiguraci Liferay portálu je třeba provést nastavení dvou portálových proměnných. Obvykle se úpravy portálových proměnných provádí v souboru portal-ext.properties, ale pokud tento soubor z nějakého důvodu nechceme vytvářet, můžeme je napsat i přímo do portal-setup-wizard.properties, který je umístěn v adresáři, kam jsme instalovali Liferay.

Nastavíme následující proměnné:

web.server.http.port=80
web.server.https.port=443

Pokud bychom chtěli, aby Liferay generoval všechny URL adresy pro HTTPS, nastavili bychom ještě web.server.protocol=https. To ale pro nás v tomto případě nebylo žádoucí. V některých situacích bychom mohli dále nastavit web.server.host=preferovanyHost.cz, aby Liferay při generování URL odkazů používal hostname „preferovanyHost.cz“.

Po nastavení portálových proměnných zbývá už jen restartovat Liferay portál.

Závěr

Těch pár kroků uvedených výše stačí k tomu, že máme zabezpečný přístup k Liferay portálu přes HTTPS. Jednoduché, že?

Způsobů, jak zabezpečit Liferay portál i s uvedenými požadavky na přesměrování, je určitě mnoho, a pokud se o některé z nich chcete se mnou podělit, neváhejte se ozvat na můj e-mail alena.peterova@bcvsolutions.eu!

Odložené úkoly – Deffered Tasks v Oracle Waveset

Ve většině společností se účty zaměstnanců spravují k určitému datu. Při nástupu zaměstnance se mu jeho uživatelské účty (email, přístup do informačních systémů dané společnosti atd.) zpřístupní k datu jeho nástupu. Při jeho odchodu se mu naopak účty zablokují, případně smažou, k datu jeho odchodu. Níže Vám nastíním jednu z možností, jak takové řešení implementovat.

Nedávno jsme u jednoho zákazníka řešili následující úkol. Pravidelný proces, který kontroloval a aktualizoval všechny identity uživatelů každý den, se postupně s více napojenými systémy zpomalil a bylo ho potřeba nahradit úspornějším a stejně funkčním řešením. Tento proces prováděl kontrolu platnosti účtů u všech identit a podle toho případně přidával či odebíral role, tj. zakládal či blokoval uživatelské účty. U drtivé většiny identit ale žádná změna neprobíhala. Bylo tedy potřeba vytvořit proces, který se spustí pouze nad identitami, kde má proběhnout nějaká změna, např. nad zaměstnanci, jimž dnes končí pracovní poměr.

Vzhledem k tomu, že u tohoto zákazníka je nasazen Oracle Waveset, bylo možné částečně použít řešení Deffered Tasks (Odložené úkoly).

clocks

Deffered Tasks

O co se tedy vlastně jedná? V Oracle Waveset se vyskytuje standardní funkce Deffered Tasks, která umožňuje u dané identity uložit, kdy a jaký proces se má nad ní spustit. Dále je zde možné nastavit, zda se má daný proces provést pouze jednou, nebo opakovaně. Spouštění těchto tasků zajišťuje další proces – Deffered Task Scanner. Ten je spouštěn v pravidelných intervalech a zpracovává deffered tasks z minulosti. Prochází tedy pouze identity, které u sebe mají nastavené spuštění úkolu s datem v minulosti. U těchto identit spustí specifikovaný proces s parametry, které je také možné uložit u identity. Po skončení vypíše seznam identit, spouštěné procesy a výsledek.

Nasazení v našem případě

V našem konkrétním případě tedy stačí, když při každé změně data konce či začátku daného účtu bude spuštěn proces, který provede potřebné kroky. Toto datum se načítá při synchronizaci. Bylo ji tedy třeba upravit tak, aby případně k uživateli uložila odložený úkol. Příklad uložení můžete vidět níže:

<Property name='tasks'>
  <List>
    <Object name='Deffered Task'>
      <Attribute name='date'>
	<Date>2014-03-02T23:00:00.000Z</Date>
      </Attribute>
      <Attribute name='description' value='2014-03-03'/>
      <Attribute name='executeOnce' value='true'/>
      <Attribute name='accountId' value='100001'/>
    </Object>
  </List>
</Property>

Poté bylo potřeba pouze nastavit pravidelné spouštění Deffered Task Scanneru, který již bude potřebné operace spouštět každý den v pravidelnou dobu.

Tato úprava tedy nahradila zbytečně velký, dlouhý a náročný proces za optimálnější řešení, které funguje přesně na identitách, na kterých má, a neprovádí zbytečné úkony navíc. Bylo potřeba samozřejmě dopsat proces, který se spouští na zadaných identitách v zadanou dobu.

Možnost nasazení jinde

Toto řešení lze samozřejmě implementovat i v jiných podobných systémech. Data, která se ukládají k objektům, navíc nejsou nijak velká, tedy nevznikne ani velký nárok na další paměť. Pravidelný proces pro vykonávání těchto akcí se dá naplánovat na námi požadovanou dobu a tím pádem lze určit, kdy poběží tato akce, která může být v některých případech časově náročná. Navíc máme kontrolu nad tím, kdy a pro jakého uživatele se daná akce spouští. Tím pádem se vždy po doběhnutí pravidelného procesu můžeme podívat na potřebné výsledky a nemusíme je hledat mezi spoustou dalších pro nás nepotřebných záznamů.

Závěr

V tomto článku  je popsáno využití odložených úkolů v konkrétním případě. Toto řešení lze určitě aplikovat i na mnoho dalších problémů. Pokud byste měli nějaké dotazy ohledně našeho řešení, či nějaké další dotazy ohledně Oracle Waveset, neváhejte mě kontaktovat na adam.lenger@bcvsolutions.eu.

Seznámení s Hibernate ORM

V tomto článku si popíšeme základy technologie Hibernate ORM pro komunikaci Javy s relačními databázemi. Osvěžíme si znalosti o tom, co je to ORM a jak se popisují vztahy mezi jednotlivými entitami v datovém modelu. Letmo se zmíníme, jaký vztah je mezi Java Persistence API (JPA) a Hibernate. Na závěr se ve stručnosti seznámíte s použitím Hibernate v Identity Manageru CzechIdM.

Hibernate ORM

Hibernate ORM je framework v jazyce Java, umožňující objektově-relační mapování (ORM).

ORM je programovací technika, která umožňuje ukládat data objektově orientovaných jazyků do relační databáze. Vybraným Java třídám pak přísluší databázové tabulky, přičemž javovské datové typy se konvertují na SQL datové typy. ORM zpracovává také vztahy mezi objekty, které do relačních databází ukládáme. V databázi jsou pak vztahy objektů reprezentovány spojováním tabulek a cizími klíči.

Hibernate implementuje Java Persistence API. Můžeme ho tedy používat buď specificky – tak, že voláme přímo jeho metody -, nebo obecně přes rozhraní definované JPA.

Hibernate podporuje mnoho databázových dialektů. Umožňuje pracovat například s MySQL (přičemž můžeme odlišit, zda používá engine InnoDB či MyISSAM), PostgreSQL, Oracle, Microsoft SQL Server aj.

Hibernate dále vyvíjí speciální jazyk pro psaní dotazů do databáze přímo z kódu, tzv. Hibernate Query Language (HQL). HQL je inspirován syntaxí SQL, takže je dobře použitelný pro každého, kdo zná základy SQL dotazů.

Entita v Javě

Entita je samostatný typ objektu, který má své specifické vlastnosti a jehož instance jsou jednoznačně identifikovatelné.

Pro Hibernate je entita jedna Java třída, jejíž instance se ukládají jako záznamy do jedné databázové tabulky. Každá instance entity má svůj identifikátor, který se obvykle použije jako primární klíč do tabulky.

Entitní třída musí mít konstruktor bez parametrů, protože pomocí něj Hibernate vytváří objekty při načítání z databáze. Členské proměnné třídy jsou zpravidla private, používají se pro ně standardně konstruované gettery a settery. Načítání hodnot členských proměnných z databáze se může provádět pomocí lazy-loading, proto se doporučuje přistupovat k proměnným pomocí getterů (které vynutí načtení celé hodnoty).

Persistence entit

Ukládání instancí entit do databáze se provádí dvojím způsobem, v závislosti na tom, zda používáme způsob specifický pro Hibernate, nebo jeho implementaci JPA.

V prvním případě si pomocí org.hibernate.SessionFactory (objekt, který se vyskytuje v jedné instanci pro celou aplikaci) vytvoříme objekt typu org.hibernate.Session, v rámci kterého provedeme „jednotku práce“ – jednu operaci v databázi:

org.hibernate.Session session = sessionFactory.openSession();
session.beginTransaction();
session.save(nejakaEntita);
session.getTransaction().commit();
session.close();

V druhém případě použijeme javax.persistence.EntityManagerFactory, kterou dodává JPA v závislosti na konfiguraci naší aplikace, a pomocí ní vytvoříme objekt typu javax.persistence.EntityManager. Ten provádí jednotku práce podobně jako v předchozím způsobu:

javax.persistence.EntityManager entityManager = entityManagerFactory.createEntityManager();
entityManager.getTransaction().begin();
entityManager.persist(nejakaEntita);
entityManager.getTransaction().commit();
entityManager.close();

Konfigurace

Základní konfigurační soubor pro Hibernate se nazývá hibernate.cfg.xml.

V tomto souboru definujeme na prvním místě dialekt databáze, aby Hibernate používal správné datové typy a správnou syntaxi SQL:

<hibernate-configuration>
  <session-factory>
    <property name=“dialect“>org.hibernate.dialect.MySQL5InnoDBDialect</property>

V konfiguračním souboru nesmí chybět identifikace spojení do databáze. Pokud zadáme všechny potřebné údaje pro navázání JDBC spojení, Hibernate si vytvoří JDBC connection pool, který mu bude poskytovat spojení tak, jak bude třeba. Místo toho můžeme zadat existující javax.sql.DataSource registrovaný v JNDI, tedy spojení, které je spravováno naším aplikačním serverem.

<property name=“connection.datasource“>java:/CzechIdMDatasource</property>

(Komunita Hibernate doporučuje používat pro produkční prostředí spíše tento způsob. Upozorňují, že správu vlastního JDBC connection pool ještě Hibernate nezvládá úplně bez chyb).

Další důležitou vlastností je hbm2ddl.auto. Tato vlastnost určuje, co se děje s databázovým schématem ve chvíli vzniku a zániku SessionFactory, tj. při startu a skončení aplikace. Možné hodnoty jsou „update“ (při startu aktualizuje schéma na základě aktuálního nastavení), „validate“ (při startu ověří schéma, ale změny nedělá), „create“ (při startu vytvoří nové schéma, čímž přepíše původní data), „create-drop“ (při skončení smaže schéma, při startu ho znovu vytvoří).

V konfiguračním souboru jsou dále uvedeny odkazy na mapovací soubory.

Pokud používáme obecné rozhraní JPA, konfigurační soubor je META-INF/persistence.xml. Zde definujeme poskytovatele persistence, spojení do databáze a další konfigurační vlastnosti. Ty vlastnosti, které jsou určeny pro Hibernate, uvedeme s předponou „hibernate.“.

<persistence-unit name=“CzechIdM“>
  <provider>org.hibernate.ejb.HibernatePersistence</provider>
  <jta-data-source>java:/CzechIdMDatasource</jta-data-source>
  <properties>
    <property name=“hibernate.dialect“ value=“org.hibernate.dialect.MySQL5InnoDBDialect“/>
    ...

Mapovací soubory (Hibernate)

V mapovacích souborech definujeme mapování entit na databázové tabulky. Nejlépe to ukážeme na příkladu:

<hibernate-mapping>
  <class name="org.jbpm.graph.def.Node" table="JBPM_NODE">
    <id name="id" column="ID_"><generator class="native" /></id>
    <property name="name" column="NAME_"/>
    <property name="description" column="DESCRIPTION_" type="longstring" length="4000"/>
    ...

Atribut „name“ u elementu „class“ obsahuje FQN (Fully qualified name) třídy, která je entitou. Atribut „table“ obsahuje název tabulky, kam se její instance budou ukládat.
Následuje výčet sloupců.

Element „id“ definuje sloupec, který unikátně identifikuje řádek v tabulce. Nemusí to být primární klíč, ale je to obvyklé. Uvnitř elementu „id“ může být ještě definována strategie generování identifikátorů.

Element <property name="description" column="DESCRIPTION_" type="longstring" length="4000"/> definuje proměnnou „description“ mapovanou na sloupec „DESCRIPTION_“, přičemž v atributu „type“ je uveden konvertor (Hibernate mapping type), který má Hibernate použít pro překlad z Java datového typu na databázový typ. Pokud není konvertor uveden, používá se Java reflection a defaultní mapování z javovských typů na databázové typy. Není-li uveden atribut „column“, použije se pro název sloupce přímo název proměnné.

Anotace (JPA)

Místo mapovacích souborů se dají použít anotace přímo u entitních tříd a jejich členských proměnných. Názvy anotací odpovídají názvům vlastností v mapovacích souborech. Entita pak vypadá například takto:

@Entity
@Table(name = "identities", uniqueConstraints = {
  @UniqueConstraint(columnNames = { "name" }) })
public class Identity extends ViewMainEntity {
  @Id
  @GeneratedValue(strategy = GenerationType.AUTO)
  @Column(name = "id")
  private int id;

  @SignedField
  @Index(name = "name_index")
  @Column(name = "name", length = NAME_LENGTH)
  private String name;
  ...

Výhodné je, že při použití anotací vidíme ze zdrojového kódu na první pohled, jakým způsobem se entita ukládá.

Anotace jsou součástí standardu JPA. Pokud bychom tedy chtěli změnit způsob persistence dat do databáze, nemusíme při používání anotací měnit nic v kódu.

Vztahy mezi entitami

Silným nástrojem Hiberate ORM je popis vztahů mezi entitami. Každé dvě entity spolu mohou být v nějakém vztahu (relaci), přičemž jedna strana je vlastníkem relace a druhou nazýváme „inverzní strana“.

Vlastník relace je zodpovědný za udržování konzistence v datech na obou stranách relace. Při definici relace určíme pomocí CascadeType, jaké typy operací se mají v rámci relace propagovat. Například CascadeType.REMOVE způsobuje, že smaže-li se jedna strana relace, smaže se i druhá strana.

V databázi se vztah entit realizuje cizími klíči mezi jednotlivými tabulkami, přičemž cizí klíče jsou vydefinované v tabulce vlastníka relace.

Základní typy relací jsou Many-to-one resp. One-to-many, One-to-one a Many-to-many. Každý vztah si nyní ukážeme na příkladu z datového modelu CzechIdM spolu s ukázkami kódu.

Many-to-one & One-to-many

Situace: Každá identita patří právě do jedné organizace, přičemž do každé organizace může patřit více identit.

  • Entita Identity – vlastník relace
    @ManyToOne
    @JoinColumn(name = "home_organisation")
    private Organisation homeOrganisation;
  • Entita Organisation
    @OneToMany(mappedBy = "homeOrganisation", cascade = {CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH })
    private List<Identity> identities;
    

Vazba: V databázové tabulce „identities“ je vytvořen speciální sloupec „home_organisation“, který obsahuje identifikátor (primární klíč) domovské organizace identity.

Pokud bychom na straně organizace nepotřebovali znát seznam identit, které do ní patří, mohli bychom úplně vynechat proměnnou „identities“ a jakýkoliv odkaz na to, že mezi entitami Identity a Organisation je nějaký vztah. Relaci udržuje entita Identity. CascadeType bychom pak samozřejmě museli přidat do kódu k identitě.

One-to-one

Situace: Každá identita má právě jednu konfiguraci.

  • Entita Identity – vlastník relace
    @OneToOne(optional = false, cascade = CascadeType.ALL)
    @JoinColumn(name = "configuration")
    private IdentityConfigurations identityConfigurations;
    
  • Entita IdentityConfigurations
    @OneToOne(mappedBy = "identityConfigurations")
    private Identity identity;
    

Vazba: V databázové tabulce „identities“ je vytvořen speciální sloupec „configuration“, který obsahuje primární klíč konfigurace identity z tabulky „identity_configurations“.

Opět platí to, že kdyby entita IdentityConfigurations nepotřebovala znát referenci na identitu, k níž patří, můžeme celý atribut vynechat.

Při relaci One-to-one je možné definovat mapování speciálně pomocí primárního klíče. K tomu stačí použít anotaci @PrimaryKeyJoinColumn namísto @JoinColumn(name = ...). Pokud instance obou entit mají stejný identifikátor, Hibernate dokáže entity spojovat na základě tohoto identifikátoru. Výhodou je, že v databázové tabulce vlastníka relace není třeba vytvářet navíc žádný sloupec. Nevýhodou naopak to, že identifikátor instancí pak nelze snadno měnit, protože se vyskytuje ve více tabulkách.

Many-to-many

Situace: Jedna role může opravňovat uživatele k účtům na více koncových systémech (schématech). K jednomu schématu může opravňovat více rolí.

  • Entita Role – vlastník relace
    @ManyToMany
    @JoinTable(name = "roles_schemas", 
    		joinColumns = @JoinColumn(name = "role"),
    		inverseJoinColumns = @JoinColumn(name = "resource_schema"))
    private List<Schema> schemas;
  • Entita Schema
    @ManyToMany(mappedBy = "schemas")
    private List<Role> roles;

Vazba: Vytvoří se nová databázová tabulka „roles_schemas“, která udržuje informace o mapování rolí a schémat. Sloupec „role“ zde obsahuje identifikátor role a sloupec „resource_schema“ obsahuje identifikátor schématu (obojí jsou primární klíče).

Hibernate a CzechIdM

Identity Manager CzechIdM používá Hibernate ORM pro persistenci veškerých dat do databáze.

Standardní entity, které jsou součástí zdrojového kódu CzechIdM (identity, organizace, role, systémy,…), používají JPA a anotace. Konfigurační soubor pro persistenci entit je umístěn v CzechIdM-ejb.jar/META-INF/persistence.xml. Pokud bychom se v budoucnu rozhodli přejít na jiný ORM framework, ve zdrojovém kódu by to znamenalo žádné, nebo jen minimální úpravy.

CzechIdM používá jako workflow engine technologii jBPM. Tato technologie ukládá svá data do relační databáze také pomocí Hibernate ORM, přičemž používá přímo specifické metody Hibernate. Konfigurační soubor pro jBPM je umístěn v CzechIdM-ejb.jar/jbpm.hibernate.cfg/hibernate.cfg.mysql.xml a jednotlivé mapovací soubory pro entity jBPM jsou umístěny v knihovně jbpm-jpdl.jar. Výhodou tohoto přístupu je, že jsme mohli provést drobné změny v konfiguraci ukládání entit jBPM do databáze, aniž bychom museli znovu sestavovat celou knihovnu jBPM ze zdrojových kódů.

Spojení CzechIdM s databází udržuje aplikační server JBoss. V obou konfiguračních souborech je tedy uveden odkaz na tentýž datasource (java:/CzechIdMDatasource). Můžeme tedy konfigurovat či optimalizovat spojení s databází pro oba persistentní moduly zároveň.

Závěr

Tento článek obsahuje základy použití technologie Hibernate ORM zejména z pohledu Java vývojáře. Zdaleka jsme nepokryli všechny otázky, které by zvídavého čtenáře napadly, ale nic vám nebrání zaslat je na můj e-mail alena.peterova@bcvsolutions.eu!