Row-Level Security, OBIEE Privileges, and Data Filtering

[Deleted User] · Dec 12, 2016 1:04PM

That's seriously strange. Just creating app roles like admin should not have any impact whatsoever on data level security

Chad H. · Dec 12, 2016 3:15PM

Well, after a bit of research it appears that the policy - resource name: oracle.bi.server.manageRepositories allows users to bypass data filters on roles. Since it is a permission on the policy belonging to the BIAdministrator grant, any others created like it will inherit it. Of course, it does enable quite a few other activities (editing the RPD, refreshing metadata, accessing the Administration page) so caveat emptor! :-)

Thomas Dodds · Dec 12, 2016 3:15PM

An Admin needs to be able to see it all and do it all ... seems like you've got multiple people in Admin roles for which they really aren't admins. Who are your admins? Why?

OOTB there is Admin, Author, Consumer ... 99% of the time I find myself on day one of security planning suggesting an in-between role below Admin and above Author.

I also strongly suggest planning out the security model using 'real' roles and functions and applying the rules of EFFECTIVE permissions to each so you know what's going on long before you configure and implement.

Chad H. · Dec 12, 2016 3:26PM

Hi Thomas,

Yes, we have custom "Admins" who really don't need all of the privileges of an OOTB administrator. Essentially, they are a type of "Super Author," as you suggest, who may, one day, be allowed to work in the RPD, but are still proving themselves.

Thanks,

Chad

Thomas Dodds · Dec 12, 2016 3:34PM

It's that middle role that will make or break you!

[Deleted User] · Dec 12, 2016 4:17PM

Good find. hence my Q about inheritance. Hadn't remembered that "create like" actually deep-cascades the whole malarkey!

MFA for Oracle Community

Oracle Business Intelligence Applications

Categories

Row-Level Security, OBIEE Privileges, and Data Filtering

Answers