Understanding Business Objects Inheritance
February 20, 2010 by: David LaiWhen setting up user and group rules, it is important to understand inheritance and how inheritance works. Otherwise you may run into unexpected access rights for your groups and users.
Global to object level hierarchy
By default, groups and users will inherit rights from the highest level.
The highest level starts at the Global Settings level. The second level is the folder level; and finally the lowest level is at the object level. If we set rights at the current level itself, then those rights have precedence over inheritance (except if rights have explicitly been denied)
Here are a few examples of setting up a group at multiple levels
Group and User security Overlap
Use the following formulas as a guide to understand what happens when inheritance from multiple groups overlap
- Grant + Deny + Not Specified = Deny
- Grant + Not Specified = Grant
- Grant + Deny = Deny
- Not Specified = Denied
For Predefined access levels, the access level with more access will take precedence.
For example:
If user “James” is part of Group “Sales” and “Marketing”.
If “Sales” has “View” access on the Marketing Folder and “Marketing” has “Schedule” access on the Marketing folder. “James” will have “Schedule” access on the Marketing folder.
User rights take precedence over inherited rights
User rights will always take precedence over inherited rights.
For example:
User “James” is part of the “Marketing” and has “Schedule” access on the Marketing folder. However we set “James” with “View” access on the Marketing folder. View access will then take precedence.
The only time an inherited right takes precedence is if an inherited right explicitly denies access. To override an inherited deny, you must uncheck the box that inherits rights.
Recommendations
- Assign security at the folder level to groups whenever possible. Avoid setting rights for specific users on specific report objects. This will reduce the complexity of your system security model.
- Use predefined access levels whenever possible.
- Grant the “Everyone” group No Access at the global level and then grant specific rights to the appropriate groups to prevent any loopholes.
- When setting rights, make sure to include the appropriate Universes and Business Views as well since access may be denied if they are not included.
Hi David,
Thanks for the great explanation,
I have many problems with the security system in CMC but I have two in mind for now:
1.Even if a user is just a “refresh” guy, as soon as he gets a report to his inbox he can edit it since he has full ownership on his inbox, this can of course be adjusted but as a beginner it is a security breach, many organizations I work with attend to miss that “hole”.
2. Another major issue: security will be always very limited as long as people who don’t have the right to a universe can still get the result and watch it since they are not activating the universe in view mode.
Since you can’t always turn all the queries in your repo to refresh on open it would be wise to my perspective to also allow security in the view level:
When a report is opened, its universe id is recognized and checked against the user rights, if he isn’t allowed to use the universe, the report won’t open as well.
Which security problems do you recognize in the CMC security mechanism ?
Best regards
Yoav
Hi Yoav,
Thanks for your view on security.
For your first issue, I wrote on my previous article that if you want to prevent someone from refreshing in his own mailbox, that the user should have the “Copy objects to another folder” rights disabled. By default, this is disabled until you get to the Schedule access level.
For the second issue, the only way to prevent that is to further customize your security.
Unfortunately the predefined security access levels may not provide the exact specs a System Administrator may want, however in most cases, security specs are satisfied.