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í.