All posts by Alena Peterová

Kontrolované a zakázané organizace v CzechIdM

V tomto článku vás seznámím s novou funkcionalitou v CzechIdM, která umožňuje snazší implementaci centrální správy uživatelů ve společnostech se složitější organizační strukturou, což byl případ jednoho z našich zákazníků. Jedná se o funkcionalitu zakázaných organizací. Ta umožní vyjmout ze správy administrátora nějakou organizaci, ačkoliv ten samý administrátor spravuje její nadřazenou organizaci.

Centrální a lokální administrátoři

Do administrátorského rozhraní mají přístup všichni uživatelé, kteří mají v CzechIdM přidělenou nějakou roli typu “ADMIN”. Každá taková role přiřazuje svým držitelům rozličná oprávnění (čtení či editace uživatelů, rolí, systémů,…) na základě konkrétního nastavení. Ovšem aby mohl administrátor spravovat uživatele v CzechIdM, musí navíc kontrolovat tu organizaci, v níž je uživatel zařazen (tj. uživatelovu domovskou organizaci). Podobně je to i s organizacemi; administrátor může spravovat jen ty organizace, které kontroluje.

Administrátorovi je tedy možné nastavit buď plná práva na všechny uživatele, nebo vytvořit lokálního administrátora, který kontroluje pouze určitou část organizační struktury (jednu nebo více organizací). Organizační struktura je stromová; mluvíme tedy o nadřazených a podřazených organizacích, přičemž celý organizační strom má v CzechIdM jeden kořen – organizaci “top”.

Pokud administrátor kontroluje organizaci “top”, znamená to, že vidí všechny uživatele a organizace. Příkladem takového uživatele je třeba “admin”, který existuje v každé instanci CzechIdM jako centrální administrátor.

Stromová organizační struktura

Při nastavování kontrolovaných organizací se uplatňuje jednotný princip, že kořen organizačního podstromu reprezentuje celý podstrom. Má-li tedy administrátor nastavenou organizaci “Celá firma” ve svých kontrolovaných organizacích, znamená to, že kontroluje nejen uživatele umístěné přímo v organizaci “Celá firma”, ale také uživatele z jejích podřazených organizací (např. “Ředitelství”, “Odbor účetnictví”,…).

Tento princip by v ideálním případě stačil k tomu, aby se dala nastavit libovolná potřebná kombinace kontrolovaných organizací pro administrátory. Nicméně reálné situace zřídka bývají ideální a někdy může být potřeba, aby administrátor měl možnost spravovat nadřazenou organizaci, ale ne všechny její podřazené organizace. Například aby mohl spravovat uživatele v organizaci “Celá firma”, ale ne uživatele v její podorganizaci “Ředitelství”. Ideální řešení by bylo upravit organizační strukturu či umístění uživatelů v ní tak, aby takovéto výjimky neexistovaly. To však samozřejmě není vždy možné. Proto vznikly tzv. zakázané organizace.

Zakázaná organizace je výjimka z kontrolovaných organizací. V příkladu uvedeném výše jednoduše nastavíme administrátorovi, aby kontroloval “Celou firmu”, ale aby měl zakázané “Ředitelství”. Po přihlášení do CzechIdM pak bude moci spravovat uživatele celé firmy kromě uživatelů z organizace “Ředitelství” a jejích podřazených organizací; tyto uživatele ani neuvidí ve výpisu uživatelů.

Kontrolované a zakázané organizace

Kontrolované a zakázané organizace

Bezpečnost

Při implementaci zakázaných organizací bylo třeba důkladně promyslet všechny možnosti. Je zásadní, aby uživatel, kterému je tímto způsobem zakázán přístup ke správě části organizační struktury, skutečně nemohl žádným způsobem ovlivnit její nastavení. To znamená:

  • nesmí mít možnost vytvářet, editovat či mazat uživatele z nějaké své zakázané organizace
  • uživatelům, které má ve správě, nemůže nastavit, aby kontrolovali nějakou organizaci, které leží mimo jeho vlastní kontrolu (ať už přidělením kontrolované organizace, nebo odebráním zakázané organizace)
  • uživatelům, které má ve správě, nemůže odebrat kontrolu nad organizací, která leží mimo jeho vlastní kontrolu (ať už odebráním kontrolované organizace, nebo přidáním zakázané)

Při administraci tedy může dojít třeba k následující situaci:

  1. Administrátor kontroluje organizaci “top:Celá firma” a má zakázanou organizaci “top:Celá firma:Ředitelství”.
  2. Uživatel je zařazen v organizaci “top:Celá firma” (takže ho administrátor může spravovat) a na začátku nekontroluje žádnou organizaci.
  3. Administrátor nastaví do kontrolovaných organizací uživatele organizaci “top:Celá firma”.
  4. Uživatel má ve výsledku kontrolu nad organizací “top:Celá firma”, ale má zakázanou organizaci “top:Celá firma:Ředitelství”. Tuto zakázanou organizaci totiž přidalo automaticky CzechIdM při uložení změn nad uživatelem. To proto, že administrátor nesmí nikomu nastavit kontrolu nad “Ředitelstvím”, které sám nekontroluje.

Obdobně se CzechIdM chová i při odebírání kontrolovaných organizací či přidávání/odebírání zakázaných organizací.

Kontrola oprávnění administrátora se provádí na úrovni GUI i v backendu. Na úrovni GUI lze měnit přiřazení kontrolovaných a zakázaných organizací pouze v tom rozsahu, na který má administrátor oprávnění. Pokud by chtěl nastavit uživateli takovou kombinaci, která by vedla k nesmyslnému stavu (např. kontrolovaná organizace by ležela pod zakázanou organizací), CzechIdM by neumožnilo nastavení uložit.

V backendu se kontroluje oprávnění vždy v rámci metody Data.checkinView (což je jediná metoda, přes kterou lze uložit tzv. view – “pohled na uživatele” – do databáze). Ani při vynechání kontroly oprávnění v GUI tedy nelze nastavit nic, co by bylo v rozporu s oprávněními přihlášeného uživatele.

Závěr

V tomto článku jsem vám představila jednu z nových vlastností CzechIdM. Pokud by vás zajímaly detaily jejího chování či podrobnosti implementace, neváhejte mi napsat na e-mail info@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 info@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!

Managing MS Active Directory and Exchange 2010 by CzechIdM

Recently, we connected systems MS Active Directory and MS Exchange 2010 to our Identity Manager CzechIdM for one of our customers. User accounts in the AD domain and their mailboxes would be managed automatically, which would save the time of administrators of these systems and ensure that the data would be always up-to-date with the personal system. Our customer had also some specific requirements, the solution of which you will find in this article.
Continue reading

Jak zprovoznit prostředí pro vývoj portletů a jak vytvořit portlet pro Liferay

V tomto článku najdete podrobný návod, jak si zprovoznit prostředí pro vývoj portletů s pomocí nástrojů společnosti Liferay, a jak vytvořit jednoduchý portlet. Celé zprovoznění nezabere více než jednu hodinu. Na konci budete mít k dispozici pískoviště pro zkoušení všech svých nápadů týkajících se (nejen) portletů a Liferay portálu.

Continue reading

Správa MS Active Directory a Exchange 2010 pomocí CzechIdM

Nedávno jsme pro našeho zákazníka napojovali na Identity Manager CzechIdM systémy MS Active Directory spolu s MS Exchange 2010. Uživatelské účty v doméně a e-mailové schránky již budou spravovány automatizovaně, což ušetří čas administrátorům těchto systémů a zajistí vždy aktuální data podle personalistiky. Náš zákazník měl i některé specifické požadavky, o jejichž řešení se s vámi ráda podělím v tomto článku.
Continue reading

Úvod do světa portletů

Nedávno jsem se věnovala vývoji dvou portletů do portálu, které slouží jako prostředník mezi uživateli portálu a Identity Managerem CzechIdM. Jedním z nich je portlet pro změnu hesla, který umožňuje uživatelům změnit si heslo přímo z portálu zákazníka, zatímco na pozadí probíhá bezpečná komunikace s Identity Managerem, který heslo propaguje do dalších informačních systémů.
V tomto článku si ukážeme, co to vlastně je portlet, a také se seznámíme se základy, jak portlet vypadá uvnitř.

Continue reading

Telefonní seznam jako portlet

Každá firma potřebuje, aby mezi sebou její zaměstnanci komunikovali. Čím více zaměstnanců, tím spíše budou používat telefon či e-mail. Ovšem čím více firemních telefonních čísel a e-mailů, tím obtížněji se udržuje jejich seznam aktuální, nemluvě o možnosti v něm snadno vyhledávat. Pro našeho zákazníka jsme proto nedávno vytvořili portletovou aplikaci, která tyto úkoly s pomocí našeho Identity Managementu CzechIdM usnadňuje.

Continue reading