Standardní dokumentace OBIEE, konkrétně dokument „Server Administration Guide“ upřesňuje (v kapitole 15 „Security in Oracle BI“, odstavec Working with Groups , část „Group Inheritance“ uplatnění tzv. „least restrictive“ pravidla v případě, že uživatel je přirazen k více skupinám s „konfliktně“ nadefinovanými přístupovými privilegii:
„If there are multiple groups acting on a user or group at the same level with conflicting security attributes, the user or group is granted the least restrictive security attribute. Any explicit permissions acting on a user take precedence over any privileges on the same objects granted to that user through groups.“
Zjednodušeně řečeno, je-li definována security skupina GROUPA, která má např. právo „Read“ na subjektovou oblast SA1 prezentační vrstvy metadat a security skupina GROUPB, která má „Read“ privilegium na subjektovou oblast SA1 explicitně odebránu, pak je-li uživateli USER1 přidělena jak skupina GROUPA, tak GROUPB, pak tento uživatel má (díky „least restrictive“ pravidlu) „Read“ právo na subjektovou oblast SA1.
Toto pravidlo ovšem neplatí v případě definic tzv. „data level security“ pomocí „security filtrů“ :
Zde naopak platí „most restrictive „ pravidlo – tj. např. mám-li definovánu na úrovni business modelu logickou faktovou tabulku Fact1, a 2 security skupiny GROUPA a GROUPB, přičemž pro GROUPA nadefinuji pro tuto logickou faktovou tabulku „security filter“ a pro skupinu GROUPB tento filtr definován nebude. Pokud se uživatel USER1, kterému je přiřazena jak skupina GROUPA, tak skupina GROUPB dotazuje (v nástroji Answers) na metriky faktové tabulky, jsou mu data této faktové tabulky vždy omezena filtrem, definovaným pro skupinu GROUPA (i když zároveň patří i do skupiny GROUPB, která nad touto faktovou tabulkou žádný filtr nadefinován nemá).
Takže se v případě security filtrů nenechte zmást popisem ve standardní OBIEE dokumentací, chování BI serveru tomu neodpovídá.
Michal Zima (Teura s.r.o.)
