Zabezpečení přístupu k dokumentům v Oracle UCM, část 3

3. Přístupové seznamy (Access Control Lists)
Dalším mechanismem na definici přístupu jsou přístupové seznamy (Access Control Lists, ACLs). Jakkoli se nakonec setkáme s již známými oprávněními (permissions), jsou ACLs jistým způsobem jiné, než bezpečnostní skupiny či účty. A to především tím, že vůbec nic dopředu nedeklarují - přístup ke každé položce je možné definovat až na úrovni jednotlivé položky, tj. přímo v metadatech konkrétní položky je seznam uživatelů či skupin uživatelů, kteří mají v daném okamžiku k položce přístup. V předchozí větě bylo také naznačeno, že u ACLs se mnohem častěji dá předpokládat, že se budou v čase měnit. Řízené změny (např. v rámci workflows) jsou v pořádku, neřízené změny (odchod či změna pozice zaměstnance) se však mohou stát pěknou noční můrou - proto je třeba k implementaci ACLs přistupovat s mnohem větším rozmyslem.

ACLs se do Stellentu dostaly díky komponentě Collaboration Manager. Jejich popis proto najdeme v tomto manuálu. V poměrně nedávno uveřejněné notě na Metalinku (ID 603148.1) je však uveden i popis, jak využít tento mechanismus bez nainstalování komponenty.

Nasazení v rámci Collaboration Manageru má i tu výhodu, že poměrně úspěšně předchází riziku nekontrolovaného bujení zmatku v ACLs - ACLs se využívají jen v rámci tzv. projektů, které mají svého manažera spravujícího přístup a velmi často i předem danou délku trvání projektu, po které nezřídka dojde k zakonzervování dokumentace.

Jakkoli platí, že ACLs je skutečně možné definovat až na úrovni položky, velmi často se nastavení dědí, a to ze složky, do které je položka přiřazena (o nastavení složek viz tento manuál). Speciálními složkami jsou pak již zmíněné projekty - na této úrovni spravují přístup projektoví manažeři.

U ACLs, podobně jako u účtů také platí, že je možné v hierarchii práva nejen přidávat, ale i odebírat (do definice se přidá uživatel či skupina s prázdným seznamem oprávnění). Jinak také platí, že ACLs jsou doplňkem k ostatním mechanismům a výsledné oprávnění vzniká jako průnik všech oprávnění vztahujících se na položku. Při využití komponenty Collaboration Manager jsou automaticky všechny položky z projektů převedeny do bezpečnostní skupiny 'Project'. S výjimkou opodstatněných případů proto doporučuji tyto mechanismy raději nemíchat.

Pokračování v budoucích článcích.

Jak integrovat s UCM?

Jednou z nejčastějších otázek, zejména ze strany partnerů, je jak integrovat s UCM. Aby se na ni dalo odpovědět, je nejprve třeba vědět, za jakým účelem má integrace probíhat - jen pro příklad: jiné požadavky budou, je-li předmětem zájmu vyhledávání dokumentů uložených v UCM v organizaci, kde takovýchto úložišť je více, a jinak tomu bude, slouží-li úložiště pro ukládání nestrukturovaných dat pod velké systémy typu ERP.

Nicéně, velmi pěkný přehled na toto téma je možné nalézt v prezentaci jednoho z UCM guru Briana "Bexx" Huffa, která je k nalezení na tomto linku. Prezentace se jmenuje 10 nejoblíbenějších způsobů integrace s UCM a nabízí téměř kompletní (dnes je již 2 roky stará) výčet způsobů, jejich výhody i nevýhody, i jakési doporučení v jaké situaci který způsob užívat. Podle prezentace je 10 nejoblíbenějších způsobů těchto:

1. Secure Enterprise Search - pro federované vyhledávání (i) v UCM
2. SOAP
3. CIS/CSP (Content Integration Suite / Content Portal Suite)
   
4. Open WCM
5. JCR Adaptér
6. AJAX/Mashup
7. Aqualogic Ensemble
8. Records Management Adapters
9. BPEL Workflows
10. Custom components & Security Integrations

To, co bych dnes ještě doplnil, je

1. WebDAV (zejména spolu s využitím komponenty Folders)
2. RIDC (Remote Intradoc Client)

K některým způsobům ještě pár poznámek.

SOAP
SOAP volání je možné buď napřímo, nebo s využitím komponenty WSDL Generator s pomocí WSDL. Zajímavou volbou je i možnost přidání IsSoap=1 ke kterémukoliv URL - což jak píše Brian Huff, je jakási obdoba volání REST (ve své jednoduchosti).
Nevýhodami tohoto způsobu integrace jsou:

• bezstavovost
• to, že volaným je web server (HTTP resp. HTTPS request) se všemi plusy a mínusy, které jsou s tím spojeny
• "ukecanost" (verbosity) protokolu, která se může odrážet na výkonnosti

Výhodou je naopak to, že tento protokol je možné využít prakticky z kteréhokoliv programovacího jazyka a pro vývojaáře např. v .NETu je metodou první volby.
Normou WSDL je WSDL 1.1.
Integrace přes Web Services je explicitně vyřazena ze Standard Edice UCM.

JCR Adaptér
...splňuje normu JCR 170 na úrovní Level 1 (Read-Only repository). Využívá se při integraci UCM s portálovými prostředími. Kromě omezení jen na čtení píše ještě Brian Huff, že adaptér funguje jen s java aplikacemi (tedy např. ne s MS SharePointem, kde se užívají jiné technologie) a že se obecně od tohoto standardu ustupuje ve prospěch CMIS (Content Management Interoperability Services). Uvidíme...

CIS/CPS, RIDC
Je-li SOAP metodou první volby pro .NET, pak tyto technologie jsou naopak první volbou pro integraci s java aplikacemi.

• CIS - užívá UCPM API pro přístup ke službám k serveru. Pro inicializaci se využívají servlety, jedná se tedy o výrazně výkonnější rozhraní než SOAP
• CPS - pak užívá CIS pro přístup z portálů. CPS fakticky představuje sadu základních portletů (vyhledávání, check-in/out, vkládání, workflows, administrace)
• RIDC - představuje způsob, jak volat standardní Java API (využívané například v komponentách Content Serveru) z vnějších aplikací

Custom Components
Nakonec nesmíme zapomínat ani na možnost vytvářet vlastní komponenty. Dle Briana Huffa jsou nejlepšími kandidáty třídy odvozené z FilterEvents, které mohou obohatit jakoukoliv operaci nad dokumentem (vkládání, aktualizaci metadat, workflows). V případě volání SOAP se může část logiky přenést do komponenty - tím je možné odlehčit protokolu při zachování funkčnosti. Přesto doporučuji držet se zásady, že lze-li něco udělat standardními prostředky, mělo by se psaní vlastních komponent omezit jen na nejnutnější minimum.

Zabezpečení přístupu k dokumentům v Oracle UCM, část 2

2. Účty

Mechanismem, který dále rozšiřuje možnosti zabezpečení, jsou tzv. účty (accounts). I při jejich užití se využívá mechanismus oprávnění (permissions) popsaných v prvním článku. Na rozdíl od bezpečnostních skupin

• je využívání účtů volitelné - jejich užívání je nezbytné nejprve povolit (více viz manuál)
• účty jsou definovány hierarchicky a nejlépe odpovídají situaci, kdy je možné položky rozdělit dle nějaké pevné hierarchie (např. geograficky)
• hierarchii účtů resp. příslušnost uživatelů k organizačním jednotkám v hierarchii, ze které je možné odvodit oprávnění, je velmi často možné získat z LDAP - tento fakt se velmi často a s velkým úspěchem v praxi využívá
• oprávnění přístupu k účtu je možné přiřadit jak roli, tak přímo uživateli
  

Technicky jsou účty definovány na straně položek opět jako atribut (jedno z metadat). V rámci definice Role se pak definuje přístup k účtu podobně jako přístup k bezpečnostní skupině. Fakticky však přiřazení přístupu znamená přístup ke všem položkám, jejich účet má prefix shodný s přiděleným právem.
Účty jsou doplňkem, nikoliv nahrazením bezpečnostních skupin. Slučování těchto bezpečnostních mechanismů se děje operací průniku oprávnění vyplývajících z obou:

Pokračování v dalších týdnech.

Zhodnocení konference Oracle Fusion Middleware 2010

Jak jsme informovali, konala se minulý týden konference Oracle Fusion Middleware s podtitulem Zefektivnění procesů při práci s elektronickým dokumentem. Tímto bych chtěl ještě jednou poděkovat všem, kdo se podíleli na přípravě i kdo se jí účastnili.

Celkové ohlasy jsou vesměs pozitivní s některými konkrétními připomínkami (např. plus za prostředí a oběd, mínus za drahé parkování - to jsou bohužel dvě strany jedné mince).


Děkuji zejména těm účastníkům, kteří se s námi podělili o svoje hodnocení. Detailní hodnocení jednotlivých přednášek ukazuje následující tabulka:

Z připomínek si určitě zkusíme vzít ponaučení a budeme se těšit na shledanou na některé z příštích akcí.

Zabezpečení přístupu k dokumentům v Oracle UCM, část 1

Jednou ze základních vlastností každého ECM systému je zabezpečení přístupu k dokumentům jen pro ty uživatele, kteří jej mají mít. Jakým způsobem je tato otázka řešena v Oracle UCM?

1. Bezpečnostní skupiny
Základním a povinným mechanismem jsou tzv. bezpečnostní skupiny. Bezpečnostní skupina je atribut položky (jedno z metadat), jehož nastavením se specifikuje, kdo bude mít k položce přístup a jaký přístup systém uživateli dovolí. Vztah mezi bezpečnostní skupinou jako atributem položky a přístupem konkrétního uživatele nejlépe popisuje následující obrázek:

Každá položka má přiřazenu právě jednu bezpečnostní skupinu a každý uživatel může mít přiřazeno více rolí. V případě více rolí je celkové oprávnění uživatele dáno jako maximální oprávnění mezi všemi přiřazenými rolemi k dané bezpečnostní skupině (př.: má-li role X přiřazená uživateli oprávnění {R - Read} na bezpečnostní skupinu SG1 a role Y oprávnění {R - Read, W - Write}, pak uživatel s rolemi X a Y bude mít na položky skupiny SG1 výsledné oprávnění {RW})

Co je to oprávnění?
Kdo se fakticky o autorizaci operací je oprávnění (permission). Oprávnění může být nastaveno na čtyřech úrovních:

• R - Read; toto oprávnění dává uživateli právo číst obsah i metadata vložené položky. U mechanismu bezpečnostních skupin je třeba poznamenat, že při vyhledávání se filtr na bezpečnostní skupiny vkládá přímo do WHERE klauzule dotazu - proto se nedoporučuje definovat více než 50 bezpečnostních skupin; na druhou stranu může při vhodném navržení systému tento mechanismus vyhledávání značně urychlit
• W - Write; toto oprávnění dává uživateli právo vkládat nové verze položek dané bezpečnostní skupiny, či měnit jejich metadata. Pro změnu atributu bezpečnostní skupiny musí mít uživatel právo W v obou skupinách.
• D - Delete; toto oprávnění dává uživateli právo mazat položky
  
• A - Administer; toto oprávnění dává uživateli právo vstupovat s položkou do ad-hoc workflows. Při užití některých dalších bezpečnostních mechanismů (např. Access Control Lists) musí mít uživatel toto oprávnění, aby mohl měnit bezpečnostní nastavení.

Oprávnění je možné přiřadit pouze kaskádově - tj. uživatel s oprávněním D automaticky získává i oprávnění R a W.

Pokračování v budoucích článcích.
Více na toto téma v tomto manuálu.

Projekt eArchive pro Vodafone

Po minulém týdnu, kdy jsme si popsali nový koncept v publikaci elektronického obsahu si dáme další ochutnávku z programu naší připravované konference. Konkrétně se jedná o popis implementace jednoho projektu.

Projekt eArchive, který byl byl implementován převážné Oracle Consulting Services za spolupráce se společností Cleverlance pro Vodafone, řeší legislativní potřebu: uchovávat určitý typ dokumentů (v tomto projektu se jednalo o vydané faktury) po danou dobu (detailní faktury po dobu 6 měsíců a souhrnné po dobu 10 let).
V první fázi bylo hlavně třeba uspokojit obavy klienta z množství dokumentů - systém měsíčně přijme 2,4 mil. dokumentů, což představuje 400 GB dat. Tyto obavy byly rozptýleny už během velmi úspěšného POC, kdy po nahrání velkého množství dokumentů systém běžící na starém notebooku ve VMWare reagoval na požadavek vyhledání náhodného dokumentu prakticky bez prodlevy.
V druhé fázi, která je těsně před dokončením, se pak bude jednat o napojení systému na budoucí CRM systém (Siebel 8.1), čímž se využije další z výhod řešení postavených nad technologiemi Oracle - bezproblémová integrace s (nejen) oraclovským aplikačním balíkem.

Bezpochyby není nezajímavé, že na naší konferenci bude o projektu referovat přímo zástupce zákazníka - zprávy proto budou autentické a přímo z první ruky.

Koncept Open WCM (Web Content Management)

Při práci s webovým obsahem si až dodnes většina organizací musela vybrat mezi budováním webových stránek (statických či dynamických pomocí nějakého WCM nástroje) a budováním webové aplikace. Ty byly, zejména pokud se použil nějaký portálový framework, o něco flexibilnější (většina těchto frameworků dnes sama nabízí základní funkce pro práci s obsahem), jejich nasazení však zpravidla vyžadovalo migraci stávajících zdrojů do nového prostředí, aby se nové funkce mohly začít využívat.
Koncept Open WCM, který byl poprvé částečně implementován v release Oracle UCM 10g.4 a který bude výrazně posílen v release 11g, vychází z předpokladu, že funkce správy webového obsahu by měly být poskytovány prakticky kdekoli a uživatel by tím neměl přicházet o žádný komfort. Jen pro vysvětlení: funkcemi správy webového obsahu se zde myslí např. možnost modifikovat obsah přímo na zobrazovaných stránkách, a to buď pomocí webového editoru (dokonce inline!), pomocí desktop aplikací, pokud je obsah stránky tvořen na základě nějakého takového dokumentu (např. MS Word), či výběrem s předem vybrané sady dokumentů, obrázků atp.
Představte si např., že budete chtít převézt uživatelské rozhraní nějaké aplikace do WCM. "Starým způsobem" (např. pomocí nástroje Site Studio) by se musely všechny zdroje do úložiště nástroje a vlastníkem stránek by nově byl WCM. "Nově" postačí, když se příslušná stránka upraví tak, že namísto statického elementu původní stránky nahradí dynamický element spravovaný - od 11g - aplikačním serverem té samé aplikace a o zbytek se už postarají knihovny. Samozřejmě, budete-li chtít ukládat obsah do úložiště, bude stále nutné mít běžící i content server. Ten však už nebude vlastníkem webové stránky, ale jen obsahu na ní zobrazovaného.
Z toho vyplývá, že jedinou podmínkou pro nasazení je vlastně jen, aby spravovaná aplikace či stránky běžely nad nějakým aplikačním serverem, na kterém je možné provozovat Open WCM funkce. Původní aplikace může zůstat jinak nezměněna (např. se může jednat o PHP aplikaci). Dokonce, pokud by nebylo možné z nějakého důvodu zasahovat do kódu stránky, je možné využít mashup (WebCenter - Ensemble), ve kterém se provede "namíchání" až těsně před zobrazením koncovému uživateli.
Ve verzi 11g.1 bude (dočasně) podporován jen Weblogic Server. Technologií, ve které se bude dělat design stránek, bude JSP a vývojovým nástrojem JDeveloper (toto už je podporováno od 10g4).