Archiv pro rubriku: Programování

Novinky v Javě 8

V první čtvrtině letošního roku vydal Oracle novou verzi Javy a to konkrétně ve verzi 8. Podle slov samotných vývojářů se jedná o největší novinku od vydání Javy. Je to pravda? Pojďme se podívat na jednotlivé novinky. Nová verze Javy přinesla velké množství více či méně zajímavých novinek. My se spolu podíváme na ty nejzajímavější. Konkrétně se podíváme na témata:

  • internet věcí
  • nové API pro datum a čas
  • projekt Nashorn
  • LAMBDA výrazy
  • stream API
  • novinky v zabezpečení

Internet věcí

Tak se na to vrhneme. Jednou z největších novinek je podle Oraclu rozšíření Internetu věcí. V praxi jde o to, že Java nyní podporuje nejrůznější senzory, jež mohou být umístěny například v hodinkách, chytrých náramcích, nebo v jiné nositelné i nenositelné elektronice. To přináší větší robustnost našeho kódu a možnosti používat funkce platformy Java SE 8. Představme si, že vyvíjíme aplikaci pro chytré domácnosti. S novou Javou 8 můžeme pohodlněji pracovat se všemi čidly, které budou v chytré domácnosti potřeba. Dalším příkladem mohou být aplikace, které pracují například s chytrým náramkem a na základě dat získaných z čidel tohoto náramku nám aplikace vypočítavá odhadovaný zdravotní stav.

API pro datum a čas

Další novinku, kterou určitě uvítá každý, kdo pracuje s časovými entitami, je nové API pro datum a čas. Jedná se o package java.time. Pro ty z Vás, kteří uvidíte podobnost s balíčkem JodaTime, máte pravdu. Nejedná se o žádnou kopii tohoto balíčku, ale při vytváření java.time se vývojáři nechali balíčkem JodaTime zřejmě trochu inspirovat a to není vůbec na škodu. Nový balíček podporuje reprezentaci časových údajů například i s časovou zónou, nebo si můžeme vybrat, zda-li chceme pracovat pouze s časem bez data, nebo naopak s datem bez času a podobně. Při vývoji tohoto balíčku se zřejmě nahlíželo na to, aby se s entitami dalo pracovat co nejvíce jako v reálném životě.

Clock clock;
clock = Clock.systemDefaultZone();
System.out.printf("časová zóna: " + clock + "\n");

Nejvíce vítanou novinkou tohoto balíčku je to, že všechny třídy jsou immutable a thread safe. To je vítaná novinka, protože s nimi můžeme pracovat ve více vláknech současně a zároveň se nemusíme starat o synchronizaci. Další věcí, která se mi líbila, je možnost „podvrhnout“ komponentě určitý čas při testování. Doteď pokud jsme nepoužívali JodaTime, museli jsme měnit systémový čas, a to není úplně nejelegantnější řešení. V java.time můžeme komponentě „nainjektovat“ čas, který potřebujeme, a tím například otestovat synchronizaci. V neposlední řadě bych rád také vyzdvihl nové možnosti používat periody. Ačkoliv se to může zdát jako zanedbatelná novinka, určitě nám to ulehčí vývoj aplikací.

LocalDate today = LocalDate.now();
LocalDate bigThing = LocalDate.of(2014, Month.SEPTEMBER, 18);
Period p = Period.between(bigThing, today);
        
long pocet = ChronoUnit.DAYS.between(today,birthday);
        
System.out.println("Do našeho workshopu zbývá už jen " + pocet + " dnů!!");

Projekt Nashorn

Projekt Nashorn je nový JavaScriptový engine, který běží přímo v JVM a umožňuje používat JavaScript v našich Java aplikacích. Tuto možnost nám nabízela už i Mozilla Rhino, ale Nashorn vylepšuje hlavně rychlost provádění JavaScriptového kódu a tím může naše aplikace používat jak prvky Javy, tak prvky JavaScriptu a na výkonu to nebude znát. To je zapříčiněno tím, že celý JavaScriptový kód se překompiluje do bytecode, který interpreter následně vykonává.

Funkcionální programování

Do Javy také dorazilo funkcionální programování v podobě LAMBDA výrazů. Lambda výraz je v podstatě funkce nebo zřetězení funkcí, která pro některé nebo všechny kombinace vstupních hodnot určuje výstupní hodnotu.

Lambda výrazy můžeme použít dvojím způsobem. Buďto použijeme lambda výraz anonymně, nebo za použití funkčního rozhraní můžeme předat lambda výraz například jako parametr metodě. V ukázce vidíme anonymní použití.

Collection<String> name = Arrays.asList("John", "Mary", "Anna");
        name.stream()
                .filter(a -> a.length() < 5)
                .sorted()
                .forEach(a -> System.out.println(a)
);

Stream API

Tak nyní už víme, co to je Lambda a můžeme se podívat na nějaké praktické použití. Nejvíce se používají právě ve Stream API, které se často používá s kolekcemi a na nich si ukážeme i základní práci. Každé kolekci nově přibyla metoda stream, která nám vrací funkcionální pohled. Práce s tímto streamem je podobná s prací v bashi. Používá se tam něco jako pipelina. Tedy máme kolekci, vytvoříme na ní stream a na něj aplikujeme nějakou operaci. Například nějaký filter nebo mapu. Každá tato funkce nám vrátí zase stream a na něj můžeme aplikovat zase jiný filter a podobně. Tyto operace s původní kolekcí nic nedělají, jen změním pohled na stream a nakonec, když už máme provedené všechny „lazy“ operace, tedy ty, co jen mění pohled, použijeme terminal operaci, která upraví stream zase na kolekci. Například použijeme metodu toArray(). Nyní si celý postup ukážeme na příkladu.

List<String> cislaSlovne = Arrays.asList("100", "200", "300", "400");
 int cisla[] = cislaSlovne
 .stream()
 .map(Integer::parseInt)
 .filter(num -> num < 200)
 .toArray();


 

Nejdříve jsme si vytvořili list Stringů, který jsme naplnili čísly. Dále jsme si na našem listu zavolali metodu stream(). Metoda stream() nám vrátila pohled na náš list, který jsme dále upravovali. Abychom mohli s hodnotami v pohledu pracovat jako s čísly, přemapujeme si jednotlivé hodnoty na integery. Posledním krokem jsme si vyfiltrovali všechna čísla, která jsou větší než 200.

Novinky v zabezpečení

Nová Java přináší také novinky v oblasti zabezpečení. Nově přináší nativní podporu TLS. Transport Layer Security neboli TLS jsou protokoly, které umožňují zabezpečenou komunikaci na internetu. TLS zabezpečuje komunikaci proti odposlouchávání nebo falšování zpráv, a to pomocí autentizace pro koncový bod. Jedná se tedy o to, že koncový bod, tedy webová aplikace jako například webový prohlížeč, není autentizován, ale server, se kterým komunikuje, autentizován je, takže prohlížeč vždy ví, s kým komunikuje.

Další novinku ocení všichni ti, kdo plánují svoje data šifrovat. Java 8 přináší totiž nativní podporu NSA Suite B Cryptographic Algorithms, což je balíček algoritmů, které pomáhají uchránit data při transportu přes nezabezpečený internet proti útokům hrubou silou. Tyto algoritmy jsou velmi silné a jejich prolomení je v podstatě nemožné. Další silné algoritmy od NSA jsou obsaženy v balíčku suite A, ten je ale přísně tajný a používá ho USA ve státní správě a o algoritmech v tomto balíčku se neví v podstatě nic. V suitě B jsou obsaženy například algoritmy pro šifrování, které používají klíče s délkou 128 nebo 256 bitů. Dále je obsažen algoritmus pro podporu digitálního podpisu (Elliptic Curve Digital Signature Algorithm (ECDSA). Tento algoritmus používá k zabezpečení eliptických křivek o velikosti 256 a 384 bitů.

Závěr

V tomto článku jsme si shrnuli nejvýraznější novinky v novém vydání Javy. Jedná se určitě o krok správným směrem, který nám přináší nové možnosti, jak rozšířit možnosti vývoje nových druhů aplikací. Ať už se chystáte vytvářet aplikaci, co bude číst data z čidla srdečního tepu, nebo jen chcete efektivněji selektovat hodnoty v kolekci, Java 8 Vám práci ulehčí.

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.

Funkčnost a GUI Archivu

Mezi primární funkci archivu patří samozřejmě archivování různých objektů. Také je možné jej prohledávat na základě zvolených kritérií či exportovat vybraná data do csv souboru. Tyto funkce jsou snadno přístupné administrátorovi přímo z administrátorského rozhranní CzechIdM pod záložkou uživatelé a podzáložkou archiv. Takto vypadá hlavní stránka archivu:

archiveMain

V hlavičce stránky je možné definovat kritéria, podle kterých si přejeme vyhledávat archivované objekty. Mezi možnosti patří hledání podle názvu, datum archivace, typu, či hodnoty atributu. Strukturu samotných objektů vysvětlím dále v článku. Po vyhledání se zobrazí seznam objektů odpovídajících výše uvedeným kritériím. V případě, že bychom si chtěli vyhledané objekty vyexportovat a dále s nimi pracovat, stačí pouze kliknout na tlačítko export a jen si uložit výsledný soubor.

archiveExport

Volání metod archivu z Java kódu

Nyní se zaměřím více na technickou stránku věci, aneb jak je možné obsluhovat archiv přes java kód. Pro obsluhu archivu vznikly nové statické metody na třídě data, které je možné volat kdekoliv z kódu. Protože automaticky se v CzechIdM nic nearchivuje, je nutné tuto akci vždy vyvolat explicitně. Například můžeme upravit workflow smazání uživatele, kde před samotným vykonáním smazání tohoto uživatele zaarchivujeme.

Archivování

Archivované objekty sice musí splňovat předepsanou strukturu vyžadovanou archivem, ale de facto je možné archivovat jakýkoliv serializovatelný objekt. Pro zaarchivování objektu musíme předat archivu meta informace jako jsou jméno a typ objektu a dále seznam jeho atributů, které si přejeme uložit. Každý ukládaný atribut se skládá ze jména a serializovatelné hodnoty. Při ukládání se tato hodnota uloží i v podobě řetězce z důvodů vyhledávání. Přesně s těmito atributy zavoláme metodu Data.archive a CzechIdM se postará o zbytek.

Vyhledávání v archivu

Pro prohledávání archivem používáme metodu Data.archiveSearch, které předáme kritéria vyhledávání. Ta nám vrátí iterátor, přes který můžeme procházet archivovanými objekty. Z důvodu rychlosti a optimalizace vrací iterátor pouze základní meta informace o archivovaném objektu, pro vytáhnutí celého objektu včetně jeho atributů musíme zavolat metodu Data.archiveGetElement, které předáme ID daného objektu. Zde je krátká ukázka jak definovat kritéria, které vyhledají objekt typu „IDENTITY“, zaarchivovaný před týdnem mající atribut manager nastavený na „Doe“:

Criteria criteria = new eu.bcvsolutions.idm.data.dto.Criteria();
criteria.add("type", "IDENTITY", Relation.EQ);
Calendar cal = Calendar.getInstance();
cal.setTime(new Date());
cal.add(Calendar.DAY_OF_YEAR, -7);
criteria.add("archiveDate", cal.getTime(), Relation.GT);
criteria.createAlias("attributes", "attrs");
criteria.add("attrs.attrName", "manager", Relation.EQ);
criteria.add("attrs.attrValueAsString", "Doe", Relation.EQ);

Export

Export z archivu funguje podobně jako prohledávání. Na vstupu se mu předají kritéria a on vyexportuje všechny objekty odpovídající těmto kritériím do csv souboru. Ovšem protože každý objekt může mít k sobě napárovaný neomezený počet atributů a nás může zajímat pouze nějaká jejich podmnožina, je možné specifikovat pouze ty atributy, které se mají k daným objektům vyexportovat. Tyto atributy definujeme v mapě, které funkci exportu předáme. Jako klíče jsou názvy atributů, které chceme vyexportovat. Můžeme definovat i jejich hodnoty, které slouží pro přejmenování sloupce pro účely exportu. V případě, že chceme vyexportovat všechny atributy, předáme místo mapy null. Zde je názorná ukázka, jak vyexportovat všechny objekty archivu a k nim pouze atributy „MANAGER“ a „ROLES“ u kterých budeme ale chtít, aby se v exportu objevily jako „manažer“ a „role“.

Criteria criteria = new eu.bcvsolutions.idm.data.dto.Criteria();
Map<String> attributes = new HashMap<String>();
attributes.put("MANAGER", "manažer");
attributes.put("ROLES", "role");
File file = Data.archiveExport(criteria, attributes, "archiv_export");

Závěr

Po přečtení tohoto článku by jste měli být schopni sami umět ovládat archiv přes Java kód. Kdyby jste měli nějaké dotazy ohledně archivu či potřebovali poradit, kontaktujte mě přes filip.mestanek@bcvsolutions.eu.

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.