SAP BusinessObjects Security - The Wonders of a Top-Down Methodology

By Rick Epstein

Forget the 7 Wonders of the World: these 7 wondrous tips will help you get started with building your own highly effective security model. Taken together, these best practices constitute a "top-down" methodology. That is, starting from these principles, we can easily drill down to enable efficient and effective management of the most granular aspects of SAP BusinessObjects security. They lay the groundwork. As every project manager knows, the more efficiently you prepare upstream, the less thrashing you'll do downstream.

So, here we go:

1.  Create a structure that will allow you to add all of your users easily and to specify their rights clearly.
2. Apply No Access to Everyone on all top level folders.
3. Never break inheritance.
4. Never use explicit denial of access.
5. Enforce access rights on users by adding them to groups.
6. Never apply security individually to users—only to groups.
7. If you are using Active Directory authentication (with or without Single Sign On), never assign permissions directly on imported AD groups.

Let’s delve into these a little bit more:

1. Create a structure that will allow you to add all of your users easily and to specify their rights clearly;

There are many ways to structure your groups.  I would recommend having the groups mirror the structure of your folders.  In this way, users can inherit rights from parent groups and parent folders.  If you allow inheritance from both parent groups and folders and you haven’t set up one of their permission settings (the folder or group) correctly, a user will inherit unintended permissions.

2. Apply No Access to Everyone on all top level folders;

We’ve discussed the importance of this concept in a previous blog post.  I can’t stress enough how important it is to start with a clean slate.  Set the Everyone group to “No Access” for all top level folders and all applications.  Likewise, make sure that the Administrators group has “Full Control” in all of these areas.

3. Never break inheritance

Never is a strong word.  I was always taught in school that, on a multiple choice question, if one of the answers used the words always or never to not choose that choice as it would likely be wrong.  How true that advice was.  Let’s rephrase this tip by saying that most of the time you shouldn’t break inheritance.  If you follow tip 1 above, then it would be appropriate to break inheritance on each folder when assigning 1 group access to 1 folder and not wanting that to cascade down.  For example, let’s say that we have 3 folders:  A, B, & C.  B is a subfolder of A and C is a subfolder of B.  Likewise, we have 3 groups GroupA, GroupB, and GroupC.  We have arranged these groups hierarchically to inherit from their parent.  GroupB is beneath GroupA and GroupC is beneath GroupB.  We assign GroupA view access on Folder A.  By inheritance, GroupA would be able to have view access on Folders B and C.  Therefore, we would want to remove the inheritance on Folder B for GroupA.

4. Never use explicit denial of access;

In this case, the never is true.  The only circumstance under which you would consider setting an explicit denial is if you had a custom group set up where you wanted to deny its users the ability to do something that was granted by their other group memberships.  For example, I have occasionally created a group that denies a user to export a report’s data.  We assign this group to certain folders. We add users to this group.  When these users access any report in these folders, they are not able to export the report’s data.  The scope for this explicit denial should be viewed with a very narrow and specific focus.

5. Enforce access rights on users by adding them to groups
6. Never apply security individually to users—only to groups

Tips 5 and 6 are flipsides of the same coin. These are 2 simple rules that should make a lot of sense.  Apply security on groups and their access to folders/applications.  By adding users to these groups, the users will inherit the rights of the groups to which they belong.

7. If you are using Active Directory authentication (with or without Single Sign On), never assign permissions directly on imported AD groups

I talked about this in my last post.  The problem with applying security directly on an Active Directory group is that it moves security outside of the BI deployment, creating a very large potential for unintended consequences.

If there is an Active Directory server upgrade, or service pack, or other maintenance, Active Directory communication may be interrupted, and groups can be "reset". While such a reset doesn’t affect the Windows environments, it can have an adverse effect on SAP BusinessObjects Active Directory integration. For example, an Active Directory group mapped in SAP BusinessObjects may become "unreadable" by SAP BusinessObjects. When you re-import or re-map that Active Directory group, you would need to set up all permissions on that group all over again. A far easier and better solution is to make Active Directory groups part of SAP BusinessObjects Enterprise groups and have security assigned on those Enterprise groups only.

Next in the security blogging series: Remediation, or how to find and repair gaping holes in your current security model